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DETAILED ACTION 
Priority 

1 . Receipt is acknowledged of papers submitted under 35 U.S.C. 1 19(a)-(d), which 
papers have been placed of record in the file. 

Specification 

2. The abstract of the disclosure is objected to because of the reasons below. 
Correction is required. See MPEP § 608.01(b). 

3. Applicant is reminded of the proper language and format for an abstract of the 
disclosure. 

The abstract should be in narrative form and generally limited to a single 
paragraph on a separate sheet within the range of 50 to 150 words. It is important that 
the abstract not exceed 150 words in length since the space provided for the abstract 
on the computer tape used by the printer is limited. The form and legal phraseology 
often used in patent claims, such as "means" and "said," should be avoided. 

Claim Rejections - 35 USC §112 

4. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention, 

5. Claim 9 is rejected under 35 U.S.C. 112, second paragraph, as being indefinite 
for failing to particularly point out and distinctly claim the subject matter which applicant 
regards as the invention. 

6. Claim 9 recites the limitation "said master module" on line 4. There is insufficient 
antecedent basis for this limitation in the claim. 

Claim Rejections - 35 USC § 102 

7. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 
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A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 
States. 

8. Claim 9, as best understood, is rejected under 35 U.S.C. 102(b) as being clearly 
anticipated by Dickman et al. (Dickman; U.S. Patent No. 5,323,452; cited and applied 
for the first time) or Boyle, III et al. (Boyle, U.S. Patent No. 5,717,747; cited and applied 
for the first time). 

Dickman plainly teaches adding a new call-processing module dynamically to a 
service call management system where the module reads on the nodes of Dickman and 
the identifier reads on the node name. 

Boyle also plainly teaches adding a new call-processing module dynamically to a 
service call management system where the module reads on the new calling features of 
Boyle and the identifier reads on the feature name. 

Allowable Subject Matter 

9. Claims 1-9 are allowed over the prior art of record. 

Conclusion 

10. The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. The patents to Mercouroff et al. teach call processing using 
CORBA specifications. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Harry S. Hong whose telephone number is (703) 306- 
3040. The examiner can normally be reached on Monday-Friday, alternate Fridays off. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Ahmad F. Matar can be reached on (703) 305-4731. The fax phone number 
for the organization where this application or proceeding is assigned is (703) 872-9306. 

Any inquiry of a general nature or relating to the status of this application or 
proceeding should be directed to the receptionist whose telephone number is (703) 305- 
4700. 




Harry S. Hong 
Primary Examiner 
Art Unit 2642 



September 30, 2003 
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ABSTRACT 



The invention concerns a method for providing a service for 
users of a telecommunication network. Service calls request- 
ing the execution of the service for an respective one of the 
users are routed to a service switching exchange of the 
telecommunication network or are respectively routed to one 
of several service switching exchanges of the telecommu- 
nication network. A corespondent service request is sent by 
the respective service switching exchange, that has received 
the respective service call, to a service control facility or to 
one of several possible service control facilities. For each 
such service request received from the or each service 
switching exchange a service session object, which is able to 
interact and communicate via an object infrastructure with 
other objects in a object oriented computing environment, is 
created within the or each service control facility and the 
respective service session object controls the execution of 
the service for the respective service call. 

18 Claims, 4 Drawing Sheets 
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METHOD OF PROVIDING A SERVICE TO network, in which method service calls requesting the 

USERS OF A TELECOMMUNICATION execution of the service for an respective one of the users are 

NETWORK, SERVICE CONTROL FACILITY, routed to a service switching exchange of the telecommu- 

AND PROCESSING NODE nication network or are respectively routed to one of several 

5 service switching exchanges of the telecommunication net- 

CROSS-REFERENCE TO RELATED work and in which method a corresponding service request 

APPLICATIONS is sent by the respective service switching exchange, that has 

This application discloses subject matter that is disclosed « ce ,^ ed "» «*P«* ve service caU, to a service control 
and which may be claimed in copending patent applications ***** ° r t0 ^.^V ^f bl< : semce control facdmes 

entitled "Method for Communicating Between a Service 10 ^charactenzed in that for each s«ch service request rece.ved 

«... ~ , e r-p . XIi . j from the or each service switching exchange a service 

Switching Exchange of a Telecommunication Network and , _i 

a Service Control Facility, filed Apr. 9, 1998 (U.S. Pat. No. S6SS1 °. n <*» e f whlch 18 abl P '° T ^ md , communlcale ™ 

6,266,406 Bl); and "Method of Providing at least One an <*J 6Ct '^^ cture with other objects in a object on- 

Service to Users of a Telecommunication Network, Service ented computing environment is created wnhm the or each 

r> . 1 r j c vr j » ct j j * , c service control facility and the respective service session 

Control Facility and Server Node , filed on even date 35 J , r . 

herewith (U.S. Pat. No. 6,201,862 Bl); both of which are ^ Coa \\° ,he exeCUtl ° n ° f ^ for ^ reS P ecUve 

» 1 * ... 1 service call, 
hereby incorporated by reference. 

According to a second aspect of the invention, a method 

BACKGROUND OF THE INVENTION for provisioning the execution of a service logic function 

1 Technical Field 20 w * tlun a service control facility of a telecommunication 

™ . . . ~ ... . systems, where service requests, that request the execution 

The invention concerns a method for providing a service r .1. • 1 ■ c !• . , . . 

v a luwu W « ivi yivj iuui B a i of lhe loglc function, are received by the service 

for users of a telecommunication network, a method for * 1 * -i-* «. * 1 * ■* u- u 

. . . 4 . 4 . c • 1 • r .... control facihty from at least one service switching exchange 

provisioning the execution of a service logic function within c „. . . J . . . . • j- *i_ 

F 6 , , f .... r # , • . of the telecommunication system, is characterized in that for 

a service control facihty of a telecommunication system, a • / • j * »e..i* 

4 , f ... J c . 4 17 ' „ each such service request received from the at least one 

service control facility for connecting to one or several * switcWng e i ge a ^fo,, objecti which 

service switching exchanges of a telecommunication net- ^ ^ mterac f ^ communicate via an object infrastruc- 

work and a processing node for a service control facility ^ ... t , , . t . , . . . • . 

. . r & . . ... , J - ture with other objects m a object onented computing 

connected to one or several service switching exchanges of _ . . . J . A „. f , . tt / M t , / 

, . • environment, is created within the service control facility 

a telecommunication network. . ' . . . „ J 

3q and the respective service session object handles the execu- 

2. Discussion of Related Art tion of the logfc fa nctioQ for the respective service 

Telecommunication services can be provided according to request, 

the Intelligent Network Architecture. According to a third aspect of the invention, a service 

A user of a telecommunication network requests a service control facility for connecting to one or several service 

by dialing the number dedicated to the service. The call with 35 switching exchanges of a telecommunication network, 

this number is routed through the telecommunication net- where the service control facility contains means for receiv- 

work to a service switching exchange which recognizes this ing service requests, that request the execution of a service 

call as a call requesting the service. Then, this service for a user of the telecommunication network, from at least 

switching exchange communicates via a data network with one of the service switching exchanges of the telecommu- 

a service control facility, the so called service control point. 40 nication network, is characterized by containing means for 

This service control point contains a service logic which creating for each such service request received from the at 

contains a description of the method that has to be executed least one service switching exchange a service session object 

to provide the service to the calling user. By a request of the within the service control facility, means for enabling each 

service switching exchange the execution of this method by service session object to interact and communicate via an 

the service logic is initiated and the requested service is 45 object infrastructure with other objects in an object oriented 

provided to the requesting user. computing environment, and means for executing under 

This service logic is realized as a single process handling control of the respective service session object a service 

all calls one after the other. Each of them going through a logic function for the respective service request, 

single queue. Each call is associated with a context allowing According to a fourth aspect of the invention, a processing 

the state of the call not to be lost between user interaction. 50 node for a service control facility connected to one or several 

The service is executed through a finite state machine, taking service switching exchanges of a telecommunication 

as input the TCAP message and the context of the call. network, where the processing node contains means for 

The disadvantage of this approach is that this architecture receiving service requests, that request the execution of a 
of provisioning services is that within the service control service for a user of the telecommunication network, from at 
facility an incoming request for a service has to wait for 55 least one of the service switching exchanges of the telecom- 
execution until the current one has been processed out. munication network, is characterized by containing means 
Therefore, the rate of service requests that can be handled by for creating for each such service request received from the 
the service control facility is strictly limited. at least one service switching exchange a service session 
o n ww ADV nv iwvuMTrnM otyecl, means for enabling each service session object to 
summary ut lixvfciNUUiN fi() intf > T3LCi an d communicate via an object infrastructure with 

Accordingly, it is a primary objective of the present other objects in an object oriented computing environment, 

invention to increase the number of service requests that can and means for executing under control of the respective 

be handled by a processing node that is involved in the service session object a service logic function for the respec- 

cxecution of services for users of a telecommunication tive service request. 

network. 65 Th e underlying idea of this invention is that for each 

According to a first aspect of the invention, a method for service request received from a service switching exchange 

providing a service for users of a telecommunication a service session object, which is able to interact and 
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communicate via an object infrastructure with other objects such a service request, it sends a corresponding request via 

in an object oriented computing environment, is created the network KN2 to one of the two service control facilities 

within the control facility and the respective service session SCP1, SCP2. The service is then provided under the control 

object controls the execution of the service for the respective of the respective one of the service control facilities SCP1 

service call. Therefore, the service architecture is no longer 5 aQ d SCP2. 

based on a functional design and technologies like multi- Each of the service control facilities SCP1 and SCP2 

threading or multi processing can be applied. provides one or several services S and realize a service 

Due to the introduction of an object oriented computing ; . . T , vr _ . f . . . 

environment and the special object design described above, The communication network KN2 is preferably a data 

the processing of the service requests cafbe distributed and » j?^"^^"?^ t l^l 

iL * j l. ■ u i ui* j rr i .j: * j . It is also possible that this network is a LAN (Local Area 
this proved high scalability and IT platform independency Network), a MAN (Metropolitan Area Network) or an ATM 
The redesign of the service logic according to this approach (Asynchronous Tr ^ t nelwork . 
allows for easy service ^interworking penalization distri- Pre f e rably, the switching exchanges SSP1, SSP2, 
bution and maintainability - of the software^ The design and the communication between them and the service con- 
pattern allows for taking all benefits from object onented >5 ^ facilities scpi> scp2 are designe d according to the 
programming. Intelligent Network Architecture (according to the service 
Furthermore, it allows introduction of multithreading. switching point and according to the communication 
The direct benefit is that a service session, that means the between the service switching point and the service control 
processing of a service request, is not blocked by the point), described for example in the ITU-T Q.1214 Recom- 
execution of another one. 20 mendation. 

The use of a factory allows implementation of several life If a user wants to start an service S, he dials a specific 

cycle policies for the service session objects. number for that service. The local exchange will route this 

It is further advantageous cali t0 me nearest s*™** swishing exchanges and this will 

4 . . 4 , . , jj .j a _ trigger the service switching functionality SSP to start the 

to mipkment each service by a d«hcated CORBA server. 25 ^ ^ ^ ^ b ^ a t ^ ^ scp ^ ^ 

Each call to the service is handled then by a single . „ . ' . .f /OT m x OT n . 
CORBA ob'ect* executing a Service Logic Program (SLP). An SLP is 
^ ' specific for each service, it will instruct the network on how 
to manage the creation of a service session object by a t0 handle mc ^10$. It will execute service logic, statistic 
service dedicated factory; logic, database logic, charging logic, etc. It will also provide 
to set the interface definition of a service session object as instructions for the switch (e.g., create the second leg of the 
TCAP mapped over IDL. call) and Intelligent Peripherals (IP) (e.g., announcement 
By the use of CORBA (Common Object Request Broker machines). A protocol according to the Information Net- 
Architecture) servers the service control facility implemen- working Architecture (INAP) is used for this, and INAP 
tation is simplified and scalability is ensured. messages are transported in TCAP (Transactional Capabili- 
ties Application Part) messages between the SCP and SSP. 
When designing a distributed application, first the pos- 



BRIEF DESCRIPTION OF THE DRAWING 



FIG. 1 is a block diagram presenting the architecture of a s*le system components to be distributed are identified (i.e., 
telecommunication system containing a service control what the objects of the system are and how they will be 

facility according to the invention. 40 grouped into larger objects that will be distributed). 

FIG. 2 is a block diagram presenting a first object archi- ^ breaking down of the SCP into objects offers some 
lecture of the telecommunication system. possibilities. FIGS. 2 to 3 depict these organized into dif- 

FIG. 3 is a block diagram presenting a second object fercnt architectures. All state information for handling one 

architecture of the telecommunication s^tem. cal1 was ke P l ^ etncr and * ^l d D da * was ?& aa * 

m ^ A . . , , . , . , , . as into objects. So, one possibility for SCP objects is a script 

FIG. 4 is a block diagram presenting a third object object lhat executes tQC { ic fof one call and M 

architecture of the telecommunication system. object ^ data object 

FIG. 5 is a block diagram presenting a object architecture valucs of me data ob j ccts m kcpt in a data base, so 

of a service switching exchange for the telecommunication having data objects that hide the use of a database is 

system. 5Q preferable (i.e., certain independence on the database). The 

DETAILED DESCRIPTION OF PREFERRED catch lies * the fact **** these objects CORBA 

cKjfuonffcifcxrrc objects gives us a considerable overhead when methods 

EMBODIMENTS ✓ . j „ u . 1 \ n j o 

(e.g., to read or write attribute values) are called on them. So, 

FIG. 1 shows a telecommunication system TS with an the system performance would become unacceptable, 

telecommunication network KN1, a subscriber terminal T 55 The script object could be decomposed into a service 
assigned to a subscriber A, a communication network KN2 execution engine and an SIB graph. So, SIBs could become 
and two service control facilities SCP1 and SCP2. distributed objects too. If database objects are distributed, 

The telecommunication network KN1 is for example a this offers the possibility to execute an SIB on the machine 
telephone network. It is also possible that this network is a where the particular data object resides. We can envisage a 

data network or a communication network for mixed data 60 scheme where there is a control entity (a script) that executes 
speech and video transmission. SIBs remotely (possibility of having more overhead) or a 

From the exchanges of the network KN1 two special scheme where control is passed from SIB to SIB. This trade 
designed exchanges SSP1 and SSP2 are shown. These off between getting the data and running a script on one 
exchanges are service switching exchanges that contain a machine and running parts of a script (SIBs) where the data 

service switching functionality SSP. To these exchanges 65 resides is certainly worth investigation, 
service request calls from the subscriber of the network are The SSPs main functionality is to provide a hook between 
routed. When such a service switching exchange receives the call processing and the IN system. An SSP server must 
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at least have an object that bridges between the normal Call 
Control Function (CCF) and an object that bridges between 
the Switching Function (SF). Also an object that bridges 
between Specialized Resources (SRF) (e.g., announcement 
equipment), seems to be obvious. In FIG. 5, these objects are 
depicted as a Switching Control, Call Control and Special 
Resources Object. We also need an object, Call Handler 
(CH) that interlaces with the SCP and the other objects in the 
SSP. There are two possibilities: there will be only one that 
handles all calls, or several, each handling one call. If we 
have several, existing only for the duration of the call, we 
also need a corresponding factory object to control the 
lifecycle of these objects. 

In the following is given the architecture of an SSP server 
on CORBA. 

For the Switching Control, Call Control and Special 
Resources objects we could have two approaches. In the first 
approach they are only interface objects between the pro- 
prietary Application Program Interface (API) of existing 
software. In the second approach they would control the 
hardware directly, what implies providing a CORBA inter- 
face to Switching Control, Call Control & Special 
Resources. In theory this would be the best solution, since 
the approach would give an overall consistent software 
architecture, in this case special IDL (Interface Definition 
Language) adapter interfaces have to be designed. 

An SMP (Simple Management Protocol) is responsible 
for service control and monitoring. In order to be able to 
control services, the SMP does not need to be a DPE object. 
What is needed is that the objects that are controlled (e.g., 
script) provide an interface to do so. For monitoring we need 
an SMP object that is able to receive "events" from the 
objects that are being monitored. In our research prototype 
we defined and implemented a trace control as an example 
on what is possible as management functionality on the SCP. 

In the previous section we have described a number of 
possibilities for CORBA objects in an IN Architecture. In 
this section we will group certain of these CORBA objects 
into a specific architecture. The sequence of the architectures 
can be seen as a possible evolution scenario, starting from 
current day's service provisioning, especially IN, products. 

The basis of the first architecture is the usage of a 
distributed database for data distribution and CORBA dis- 
tribution for distributed SCP. This architecture is designed to 
interface with existing SSPs, so the SSP is not a CORBA 
object. Since this architecture was used to implement a 
research prototype, we elaborate on it more than the others. 
FIG. 2 depicts the architecture. 

The basic components in the architecture are: 

the script: a CORBA object that handles exactly one call 

the SLI (Service Logic Interface), a CORBA object that 
handles a TCAP dialogue for, and interfaces with the 
SSP. 

the distributed DB. 

Existing IN service scripts can encapsulated in Script 
objects. 

A Script object also contains the Service Data and Call 
Context related to a particular call, and one Script object is 
instantiated per call. The interface of the Script object 
contains operations that represent the TCAP messages that 
the Script receives during its execution. 

A special Service Logic Interface (SLI) object receives 
the #7 messages from the SSP and dispatches them to the 
corresponding script object instantiation, using the ORB 
services. The interface of the SLI object contains the TCAP 
messages that can be sent to it. One SLI object is instantiated 
per call. 
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Since the Script and SLI objects exist only during the 
lifetime of a call corresponding factory objects are used to 
create and destroy them. Data objects are not CORBA 
objects, they are implemented as C++ objects. This approach 
5 hides the use of a particular database from the service logic. 
It is possible to use as database for example Oracle, 
SQLNET or ObjectSlore. The SMP has not be considered; 
we could have used the proprietary mechanism to send 
status information to it, or defined it as a CORBA object with 
an appropriate IDL interface. 

However as an example on what is possible, its easy 
possible to design and implement a small trace control 
system; each server has a tracer object, the trace control part 
of the SMP can call methods to turn traces on particular 
implementation objects on and off. The SMP also manages 

15 the database (using SQLNET). 

A script and a SLI are CORBA objects, how they are 
distributed over servers is a deployment issue. A CORBA 
server is a process running at a particular node in the system. 
There is one SLIServer in the system that interfaces with the 

20 SSP. It has one CORBA object, the SLIFactory, that is 
always present when the server is running. 

The main purpose of this object is to create new SLI 
objects when new calls are started (when a TCAP dialogue 
is opened). The SLIServer is deployed in the node that has 

25 the #7 hardware and software installed. The system can have 
a number of ScriptServers, one per available node. 

This server also has a factory object, that exists during the 
lifetime of the server itself. This factory object is registered 
in the CORBA Naming service, so that an SLI can find it. In 

3Q this way service logic distribution is facilitated. Adding 
more processing power to the system just means installing 
the new machine, running the ScriptServer on it, and the 
next time the SLI looks for a ScriptFactory a new possibility 
is available. The same mechanism also provides some 
reliability, when a machine goes down for some reason, the 

35 SLI will simply not get a reference to that ScriptServer any 
more. Note that the ScriptFactory is also to best candidate to 
put a management interface on (e.g., to change the service 
characteristics), since it is always available as long as the 
server is running. 

40 The interface between SLI and Script is defined to be 
asynchronous and in terms of TCAP primitives (BEGIN, 
INVOKE, RESULT, . . . ). This option is advantageous, since 
one of the requirements is to reuse existing IN product 
software. Another option is to define this interface in terms 

45 of INAP primitives. 

The difference between a CORBA object, a (CORBA) 
server and a process must be clear. A CORBA object 
implements an interface and runs within a CORBA server. 
The CORBA server itself is one process that runs on a host 

50 (or node). This definition is important for the relation 
between a script and a call. In the current ALCATEL IN 
product implementation a script is a process that handles 
different calls, and keeps a different call context for each of 
those. This is done for performance reasons, starting up a 

55 separate process (script) for each call takes some time. 
We could adapt a similar approach (one script handles n 
calls) in these architectures, but the fact that a script has 
multiple contexts is not that clean and it is possible to deal 
with the performance issue by having a CORBA server with 

60 multiple scripts (each handling one call). So, it is better that 
in this architecture, a host can run one or more CORBA 
servers, each running different script objects that each 
handle a specific call. 
The CORBA server is similar to the script in the current 

65 IN product, but the problem of handling multiple contexts is 
shifted from the application programmer to the CORBA 
platform. 
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A step further in this sequence of architectures, as second 
architecture, is to break down the script object into its 
components. As known, IN services are designed as a 
number SIBs that are nodes in a service logic graph. The 
execution of the script means executing SIBs and moving to 5 
the next SIB depending on data and responses coming from 
the SSP. In stead of designing this as a monolithic piece of 
software (from the SCE), it could be designed in terms 
cooperating SIBS. As known, the IN capability set 1. SIBs 
are not sufficiently defined to used them as they are. This 10 
resulted in IN platform providers having their own set of 
SIBs derived from the standard and software from SIBs is 
not reusable among platforms. 

When SIBs are defined as CORBA objects this situation 
could be broken and service providers would be able to 15 
design their own services, reusing existing SIBs (source 
code). 

Having SIBs as independent CORBA objects offers the 
possibility to execute the SIBs in different places. Instead of 
getting the data (using a distributed database, or using 20 
CORBA objects) to the place where the script or SIB is 
executed, we could start the SIB on the machine where the 
data is located. This brings benefits. We can envisage a 
scheme where there is a control entity (a script) that executes 
SIBs remotely or a scheme where control is passed from SIB 25 
to SIB. 

A third architecture breaks with traditional IN product in 
the sense that it also makes the SSP a CORBA object. In the 
previous architectures, for reliability reasons, it is still 
necessary that CORBA servers are deployed on machines 30 
that are interconnected on a rehab le LAN. In practice, with 
the current DPE implementations (TCP/IP) this means put- 
ting the machines in the same location. This technology 
restriction prevents putting the SSP on the DPE, since in 
practice SCP and SSP sites are located on different places. 35 
However, technology evolves and DPE providers (e.g., 
IONA) are looking into the possibility of porting their 
product to other transport protocols, e.g., #7 links for 
telecommunication purposes. When this happens the step to 
making the SSP a CORBA object is not that big. In this case, 40 
the SLI object would not be needed anymore, since the SSP 
object could take over its role. When a call is started it gets 
a reference to a ScriptFactory and asks to create the script 
object itself. It could then communicate with this object 
directly. Also the language used in this communication 45 
(INAP encapsulated in a TCAP based interface) can be 
simplified. This interface could be defined in terms of INAP 
primitives (e.g., provide_instruction(args), join(args)). This 
would improve (simplify) the system design and 
implementation, since the TCAP layer disappears for the 50 
application programmer. One could say that when CORBA 
is used, the application programmer must only be concerned 
with the application layer of the communication, not with 
the session layer (when TCAP is used). 

The final step would be to extend integrate a terminal (as 55 
proposed by TINA (Telecommunications Information Net- 
working Architecture)). This would mean a major change in 
user equipment. However this change is not infeasible if we 
consider the fact that more and more users get connected to 
the internet over their telephone lines. And the technology 60 
needed to have the DPE extended to the terminal is similar 
to this. The benefit of this would be that the terminal to 
network protocol could become much richer than just pass- 
ing DTMF tones as numbers. 

The above described architecture provides a solution to 65 
make especially IN platforms more scalable. Since inter- 
working with and evolution from existing products Is impor- 
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tant we presented a sequence of architectures that can be 
seen a possible evolution scenario. 

As example an implementation procedure according to 
the architecture 3 is described in the following: 

A Credit Card Calling service which existed for the UNIX 
based IN Release existing Alcatel product is to be imple- 
mented. The Credit Card Call service is a "typical" IN 
service and allows a call from any terminal to be billed to a 
particular card number. To set up that call, the user has to 
enter a card number, a PIN code and the destination number. 
If the entered data is correct, the call is completed to the 
destination address and charged to the user's card. 

An SSP simulation stub was used to generate the TCAP 
dialogue for the Credit Card Call. The SSP stub is a CORBA 
object that sends and receives the same TCAP messages that 
an SSP would. The SSP stub is capable of simulating 
different call scenarios, can generate different call loads and 
can repeat a scenario an arbitrary number of times. 

Another general issue for the use of CORBA in an IN 
oriented service provisioning architecture is the interwork- 
ing of CORBA-based IN with legacy IN applications. 

This interworking can be achieved with the use of Adap- 
tation. It is related to the way a CORBA based infrastructure 
can communicate with the legacy of switching systems, 
namely SSPs. 

There are two approaches possible: 

1) Definition of an Adaptation Unit which is an application 
level bridge that provide the mapping of SS7 and TCAP 
primitives into IDL invocations. This approach is similar to 
one taken by the XoJIDM group for the CORBA/CMIP 
gateway. The result of their works can be reused especially 
the static mapping of GDMO/ASN.l to IDL interfaces. 

In order to minimize the impact on existing systems, 
CORBA should provide framework services and tools in 
order to achieve this mapping. The availability of such 
framework will allow interworking of CORBA-based IN 
with a variety of existing hardware such as SCPs and HLRs. 

Such application level bridge should be characterized by 
high availability and high performance without being a 
bottleneck for a distributed system. However for the 
required real-time performance, this is an intermediate solu- 
tion towards full IN CORBA-based systems. 

This approach would involve building an IDL interface to 
represent application level protocols such as MAP and INAP 
and others which are based on the TCAP layer. The TCAP 
layer provides a "ROSE-like" asynchronous RPC service 
over the SCCP layer. And basing the bridge on TCAP will 
exclude the use of circuit related signaling protocols such as 
1SUP and TUP from the solution. 

Like in the XoJIDM approach, there should be a static 
translation of the INAP/TCAP specification to IDL inter- 
faces which will be done by a dedicated compiler. Thus, any 
INAP dialect can be converted to appropriate IDL interfaces. 
These applications level bridges would implement these IDL 
generated interfaces and dynamically perform conversion 
between IDL-derived types and their ASN.l equivalents. 

CORBA nodes using the protocol specific bridges would 
generally run two servers, one each for processing outgoing 
and incoming invocations. Since TCAP is a connectionless 
service the gateway will have to maintain state in order to 
match invocations to responses and exceptions. 

2) Usage of SS7 as an Environment Specific Inter-ORB 
protocol (ESIOP): 

A possible solution is to map the CORBA GIOP on top of 
SS7 or to build a new Extended protocol (ESIOP) on top of 
the SS7 layers. 

The ESIOP solution would essentially use an SS7 proto- 
col as a transport for the GIOP protocol. CORBA objects 
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would be visible across the SS7 network in exactly the same reliability which denotes requirements that define accept- 

manner as they would be across the Internet with the able behaviors for the distributed applications in the 

CORBA HOP. This would allow as ORB to use existing SS7 presence of hardware and software failures. In this case 

infrastructure as transport. two types of reliability can be identified; the integrity 

It should be noticed that existing signaling networks were 5 state and the availability; 

never dimensioned to support the sort of traffic which will be manageability which denotes requirements that enable 

exchanged by CORBA nodes. However, there is a potential ease of development, deployment and operation for 

benefit in this approach by exploiting the fault tolerant complex applications (in this case maintainability, (re) 

nature of the SS7 network. configurability and extensibility of CORBA applica- 

The first issue here is the choice of SS7 protocol access 10 tions. 
level for this solution. The two principal choices are TCAP An asynchronous Invocation model commonly used by 
and SCCP: GIOP at TCAP level: IN applications is required. Thus, asynchronous and option- 
It should be possible to use TCAP for carrying GIOP ally isochronous invocation model is required with the ORB. 
messages since IT is essentially a ROSE-like service. Ser- The requirement here is a client side programming model 
vices which make use of TCAP must define their operations is which potentially supports a lightweight asynchronous corn- 
using ASN.l modules. It is envisaged that ASN.l macros munication mechanism incorporating a mandatory callback 
would be used to define the operation set: Request, Reply, (or ORB "upcall" type mechanism) and optionally a 
CancelRequest, LocateRequest, LocateReply, CloseConnec- "Futures" type programming model, 
tion and MessageError. These operations correspond to the For the same object, both asynchronous and synchronous 
GIOP primitives. The gateway would be responsible for 20 models should co-exist. The maximum concurrency level is 
converting CDR format, of the form used by GIOP, into a defined in the configuration (e.g., QoS parameters), and has 
form transportable using ASN.l types (possibly as an to be controllable, with the possibility of queuing the request 
opaque buffer with BER encoding). or returning an exception. 

While it should be possible in principle to use TCAP as A basic fault detection support should be provided by the 

the basis for the ESIOP, it is not suitable because of: 25 ORB runtime for any object which needs it. This can be done 

the complexity of the implementation. by a timer which is implicit set and managed in the client 

the overhead incurred in by the TCAP layer in process. 

addition to basic transport Flexibility and Scalability: 

the asynchronous nature of the protocol. ^ 0RB should be able t0 su PP ort applications handling 

ESIOP at SCCP Level: 30 a ^ ar ^ e numoer °f objects and should be able to support 

The other choice for implementing the SS7 ESIOP is at manv simultaneous connections to remote objects, 

the SCCP level The SCCP provides services corresponding The memory cost of an unused remote interface reference 

to the OSI-RM network layer functionality. It can operate in m a ^ ven ca P sule Unix process) should be of the order 

both connection-oriented and connectionless mode. It of a standard language pointer. 

should be feasible to use the SCCP to transport GIOP 35 A l W icdi telecommunications environment comprises 

messages although the ESIOP code may be required to objects of very different granularities in both space (memory 

perform its own transport layer functions (e.g., end-to-end slze ) and tune ( ob j ect lifetime and duration). A scalable 

flowKx>ntrol and segmentation/re-assembly). It should be ORB should support objects at different levels of granularity, 

possible to address CORBA nodes using the "Global Title" and mmiraize the overhead associated with the handling of 

mode ofSCCPaddressing.lt would appear that using SCCP 40 sma11 and volalile and of connections to remote 

as the basis for an ESIOP for the SS7 network would be the objects. 

best approach. To acmeve some of the ORB fault-tolerance and 

The following requirements are advantageous for a object ^liability, the CORBA object model could be enhanced to 

oriented environment for an infrastructure in which a service support groups of objects or globally known as group 

session object interacts (described by hand of the CORBA 45 comm unication such as those described, 

environment): Reliability and Availability: 

in terms of functional requirements, CORBA should ? T*Tt ^TlT' ^ ™? 

provide • replicated distributed objects can be introduced in CORBA. 

Thus the critical components of the application are imple- 

asynchronous Invocation model and support for group 50 me nted through repUcated objects. This replica management 

communication in the ORB; can te hand!ed automatically by the ORB such that clients 

proper hooks for extending the ORB with security, trans- interacting with a given server object is not aware if it is 

action and replication mechanisms; replicated or not. The degree of replication can be deter- 

node management and minimal object lifecycle facilities; mined by the desired level of reliability which can be 

a time service and native monitoring facilities for captur- 55 mea sured with the number of maximum number of concur- 

ing both computational and engineering events; rent faiIures ; the nature of the failure which can be typed 

support for multithreading with flexible event-to-thread < malicious or benign); and the type of reliability property 

mappings Deing ^BP 1 sucn ^ integrity or availability. High avail- 

Thc non-functional requirements of CORBA are con- a^yorFau^ 

cerned with: 60 CORBA for distributed IN systems in order to ensure the 

m • * .u i ir i u v • . . . . same robustness as current IN systems, 

inenurying ine ievei oi scalability and object granularity Timeliness requirements can be also achieved bv the 

that the ORB should meet in the IN context; rephca £ r cxamplc> applications ^ Qeed tQ y have 

identifying the performance level that the ORB must bounded and predictable delays will be implemented 

achieve in terms of latency, throughput, etc.; 65 lhrough rep iicated objects. Each replica is able to process 

providing a predictable ORB core by instrumenting and locally all of the methods defined for the object. In the 

documenting the time behavior of the platform; absence of failure, a client can use any of the responses to 
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a method Invocation as its result, (the invocations in this 7. A method as claimed in claim 5, characterized in that 

case is perform synchronously). the factory object implements a life cycle policy for the 

To achieve this, the ORB will have a modular structure service session object. 

allowing the implementation of different profiles, depending g A method as daimed m claim 7 cnaraclerized m mat 

on application or service requirements These : profiles give 5 me & objcct ^ lemenls a crealion 0D demand life 

an abstraction of the resources provided by the underlying , ,. c t , . 4 

_ r . „*L j i -,iu c -a cycle pohcy for the service session object, 

operatuig system. One of the ORB modules will be a failure « A , ,. , . . ■ j- . 

detector which is at the lower level of the ORB structure. u ' meth «? as datmCd m ^ ? ' characte " zed " 

And a response Invocation delay beyond a certain threshold lhe f"* 0 *? object implements an activation on demand life 

is classified as failure. Thus, the client is able to trade off 30 c y cle P obc y for the * TO 56551011 ob J cct * 

reliabihty for timeliness, the shorter the threshold, the tighter 10 A method ^ clai ™d in claim 1, characterized in that 

the bounds on delays. By replicating an object in a sufficient aU ^ncUons for controlling the execution of the service are 

number of times, the client is able to meet both timeliness implemented by a dedicated CORBA service server, 

and reliability requirements simultaneously. U- A method as claimed in claim 1, characterized in that 

Here, we have identified a requirement for a replication 1S the service session object has an interface definition which 

service with correctness, safety and liveness properties; and ^ Transactional Capabilities Application Part mapped over 

a failure detector module which is part of the ORB core. Interface Definition Language. 

Performance: 12- A method as claimed in claim 1, characterized in that 

Performance of IN are measured in number of calls per tne service session object directly receives its own message 

second for service nodes and intelligent peripherals; and 2 o mvoca tions. 

number of transaction per second for signaling control point. 13 ■ A method as claimed in claim 1, characterized in that 

These calls and transactions may involve multiple messages lne service session object receives Information Networking 

exchanged between an SSP and the Intelligent Layer. Architecture messages as message invocations from the 

To obtain the actual performance of legacy IN systems, service switching exchange, 

real-time performance of the ORB is required for the use of 15 14 - A method as claimed in claim 1, characterized in that 

distributed processing in IN systems as well as its distribu- tne service session object runs in its own thread, 

tion on a geographical scale (non centralized IN systems). 15 A method for provisioning execution of a service logic 

To achieve better performance for IN distributed systems, function within a service control facility of a telecommuni- 

the ORB call overhead should be reduced, and the perfor- cation system, wherein service requests that request execu- 

mance level that the ORB must achieve in terms of latency, 30 tion of the service logic function are received by the service 

throughput, etc., should be defined and documented. control facility from at least one service switching exchange 

What is claimed is: of the telecommunication system, comprising the steps of: 

1. A method of providing a service for users of a tele- creating within the service control facility a respective 
communication network, wherein service calls requesting service session object for each of the service requests 
execution of the service for a respective one of the users are 35 received from the at least one service switching 
routed to one respective service switching exchange of the exchange, and 

telecommunication network, and wherein a corresponding handling the execution of the service logic function for 

service request is sent, by the respective service switching cacn 0 f (ne service requests, wherein the service session 

exchange that has received one of the service calls, to a oh}eci ^ ab i e lo mteracl and communicate via an object 

respective service control facility, comprising the following 40 infrastructure with other objects in an object oriented 

steos: computing environment, and wherein the execution of 

creating within the service control facility a service ses- the service logic function is handled by the respective 

sion object for each of the service requests, and service session object, 

controlling the execution of the service for the respective 16. A service control facility for connecting to one or 

service call, wherein the service session object is able 45 several service switching exchanges of a telecommunication 

to interact and communicate via an object infrastructure network, where the service control facility contains means 

with other objects in an object oriented computing for receiving service requests, that request the execution of 

environment, and wherein the execution of the service a service for a user of the telecommunication network, from 

is controlled by the respective service session object. at least one of the service switching exchanges of the 

2. A method as claimed in claim 1, characterized in that so telecommunication network, characterized by containing 
the service switching exchange communicates with the means for creating for each such service request received 
service control facility according to the communication from the at least one service switching exchange a service 
protocols of the Intelligent Network Architecture. session object within the service control facility, means for 

3. A method as claimed in claim 1, characterized in that enabling each service session object to interact and com- 
the service session object interacts and communicates as a 55 municate via an object infrastructure with other objects in an 
CORBA object via a CORBA object infrastructure with object oriented computing environment, and means for 
other objects for controlling the execution of the service. executing under control of the respective service session 

4. A method as claimed in claim 1, characterized in that object a service logic function for the respective service 
the service control facility controls and carries out the request. 

execution of different services for users of the telecommu- 60 17. The service control facility according to claim 16, 

nication network. characterized by containing a variable number of processing 

5. A method as claimed in claim 1, characterized in that nodes for processing service session objects. 

the creation of each service session object is managed 18. A processing node for a service control facility con- 
through a factory object. nected to one or several service switching exchanges of a 

6. A method as claimed in claim 1, characterized in that 65 telecommunication network, where the processing node 
the crealion of each service session object is managed by a contains means for receiving service requests, that request 
service dedicated factory object. the execution of a service for a user of the telecommunica- 
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tion network, from at least one of the service switching 
exchanges of the telecommunication network, characterized 
by containing means for creating for each such service 
request received from the at least one service switching 
exchange a service session object, means for enabling each 
service session object to interact and communicate via an 
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object infrastructure with other objects in an object oriented 
computing environment, and means for executing under 
control of the respective service session object a service 
logic function for the respective service request. 
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(57) ABSTRACT 

The invention concerns a method for providing a service for 
users of a telecommunication network. Service calls request- 
ing the execution of the service for an respective one of the 
users are routed to a service switching exchange of the 
telecommunication network or are respectively routed to one 
of several service switching exchanges of the telecommu- 
nication network. A corresponding service request is sent by 
the respective service switching exchange, that has received 
the respective service call, to a service control facility or to 
one of several possible service control facilities. The service 
request is routed to a particular one of a plurality of servers 
of the service control facility, which are formed on top of an 
object infrastructure within an object oriented computing 
environment The particular server acts as service repository 
server and determines another one of the plurality of servers 
that is available and able to execute the control of the service 
for the respective service call. 

22 Claims, 5 Drawing Sheets 
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METHOD FOR PROVIDING AT LEAST ONE 
SERVICE TO USERS OF A 
TELECOMMUNICATION NETWORK, 
SERVICE CONTROL FACILITY AND 

SERVER NODE 5 

CROSS-REFERENCE TO RELATED 
APPLICATION 

This application discloses subject matter that is disclosed 
and which may be claimed in copending applications 10 
entitled, "Method for Communicating Between a Service 
Switching Exchange of a Telecommunication Network and 
a Service Control Facility", filed Apr. 9, 1998 (Atty. Docket 
902-679); and "Method of Providing a Service to Users of 
a Telecommunication Network, Service Control Facility, 15 
and Processing Node", filed on even date herewith (Atty. 
Docket 902-682); both of which are hereby incorporated by 
reference. 

BACKGROUND OF THE INVENTION 20 

1. Technical Field 

The invention concerns a method for providing at least 
one service to users of a telecommunication network, a 
method for provisioning the execution of service logic 2 s 
functions within a service control facility of a telecommu- 
nication systems, a service control facility for connecting to 
one or several service switching exchanges of a telecom- 
munication network and a server node for a service control 
facility connected to one or several service switching 30 
exchanges of a telecommunication network. 

2. Discussion of Related Art 

Telecommunication services can be provided according to 
the Intelligent Network Architecture. 

A user of a telecommunication network requests a service 35 
by dialing the number dedicated to the service. The call with 
this number is routed through the telecommunication net- 
work to a service switching exchange which recognizes this 
call as a call requesting the service. Then, this service 
switching exchange communicates via a data network with 40 
a service control facility, the so called service control point. 
This service control point contains a service logic which 
contains a description of the method that has to be executed 
to provide the service to the calling user. By a request of the 
service switching exchange the execution of this method by 45 
the service logic is initiated and the requested service is 
provided to the requesting user. 

The service switching exchange is closely linked to a 
service control facility. The configuration of this link is 5Q 
made through basic proprietary tools provided by the service 
switching exchange/service control facility pair vendor and 
do not allow easy and dynamic configurations. 

This service logic is realized as a single process handling 
all calls one after the other. Each of them going through a 55 
single queue. Each call is associated with a context allowing 
the state of the call not to be lost between user interaction. 
The service is executed through a finite state machine, taking 
as input the TCAP message and the context of the call. 

The disadvantage of this approach is that this architecture 60 
of provisioning services is inflexible and does not make 
good use of the underlying data processing systems. 

SUMMARY OF INVENTION 

Accordingly, it is a primary objective of the present 65 
invention to improve the data processing characteristic of a 
service control facility. 
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A first aspect of the invention is a method for providing 
at least one service to users of a telecommunication network, 
in which method service calls requesting the execution of 
the service for an respective one of the users are routed to a 
service switching exchange of the telecommunication net- 
work or are respectively routed to one of several service 
switching exchanges of the telecommunication network. 
Also in this method of providing service, a corresponding 
service request is sent by the respective service switching 
exchange, that has received the respective service call, to a 
service control facility. This method is characterized in that 
the service request is routed to a particular one of a plurality 
of servers of the service control facility, which are formed on 
top of an object infrastructure within an object oriented 
computing environment. This method is also characterized 
in that the particular server acts as service repository server 
and determines another one of the plurality of servers that is 
available and able to execute the control of the service for 
the respective service call. 

A second aspect of the invention is a method for provi- 
sioning the execution of service logic functions within a 
service control facility of a telecommunication system, 
where service requests, that request the execution of a 
service logic function, are received by the service control 
facility from at least one service switching exchange of the 
telecommunication system. This method is characterized in 
that the service request is routed to a particular one of a 
plurality of servers of the service control facility, which are 
formed on top of an object infrastructure within an object 
oriented computing environment. This method is also char- 
acterized in that the particular server acts as service reposi- 
tory server and determines another one of the plurality of 
servers that is available and able to execute the respective 
service request. 

A third aspect of the invention is a service control facility 
for connecting to one or several service switching exchanges 
of a telecommunication network, where the service control 
facility contains means for receiving service requests, 
requesting execution of a service for a user of the telecom- 
munication network from at least one of the service switch- 
ing exchanges of the telecommunication network. This 
service control facility is characterized by containing a 
plurality of servers, which are formed on top of an object 
infrastructure within an object oriented computing 
environment, by containing means for routing the service 
request to a particular one of the service control facility, and 
by containing the particular server acting as service reposi- 
tory server and determining another one of the plurality of 
servers that is available and able to execute the respective 
service request. 

A fourth aspect of the invention is a server node for a 
service control facility connected to one or several service 
switching exchanges of a telecommunication network, 
where the server node contains means for receiving service 
requests, requesting execution of a service for a user of the 
telecommunication network from at least one of the service 
switching exchanges of the telecommunication network. 
This server node is characterized in that the server node is 
formed on top of an object infrastructure within an object 
oriented computing environment, and contains means for 
determining another one of a plurality of server nodes which 
are formed on top of the object infrastructure within the 
object oriented computing environment. This server node is 
also characterized in that it is available and able to execute 
the respective service request. 

The underlying idea of this invention is to implement each 
service that is offered by the service control facility by one 
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or many servers, which are formed on top of an object 
infrastructure within an object oriented computing environ- 
ment and to provide a particular server, a service repository 
server which determines the one of the servers that has to 
execute the service for an incoming service request. 

Therefore, the service architecture is no longer based on 
a functional design and technologies like multithreading or 
multi processing can be applied. Further, an open way to 
distribute service execution united around one or several 
service switching exchanges is offered. 

With the service repository server distribution is trans- 
parent and system configuration is very easily achieved 
through plug and play. The scalability of the system is 
ensured and easy to realize through an open interface. 

The introduction of CORBA based distribution provides 
high scalability and IT platform independence. It allows for 
easy service interworking personalization, distribution and 
maintainability of the software. 

In the approach where the link between the service control 
facility and the service switching exchange conforms to a 
OMG CORBA 2.0 specification, the configuration of pro- 
cessing nodes and of server nodes must take advantage of 
the underlying CORBA platform. 

Due to the introduction of an object oriented computing 
environment and the special object design described above, 
the processing of the service requests can be distributed and 
this proved high scalability and IT platform independence. 
The redesign of the service logic according to this approach 
allows for easy service interworking personalization, distri- 
bution and maintainability of the software. The design 
pattern allows for taking all benefits from object oriented 
programming. 

Furthermore, it allows introduction of multithreading. 
The direct benefit is that a service session, that means the 
processing of a service request, is not blocked by the 
execution of another one. 

The use of a factory allows implementation of several life 
cycle policies for the service session objects. 

It is further advantageous 

to manage the creation of a service session object by a 

service dedicated factory, 
to set the interface definition of a service session object as 
TCAP mapped over IDL. (Interface Definition Lan- 
guage which is used to describe the interface of an 
object in language-neutral terms). 
By the use of CORBA servers the service control facility 
implementation is simplified and scalability is ensured. 

These and other objects, features and advantages of the 
present invention will become more apparent in light of the 
detailed description of a best mode embodiment thereof, as 
illustrated in the accompanying drawing. 

BRIEF DESCRIPTION OF THE DRAWING 

FIG. 1 is a block diagram presenting the architecture of a 
telecommunication system containing a service control 
facility according to the invention. 

FIG. 2 is a block diagram presenting a first object archi- 
tecture of the telecommunication system. 

FIG. 3 is a block diagram presenting a second object 
architecture of the telecommunication system. 

FIG. 4 is a block diagram presenting a third object 
architecture of the telecommunication system. 

FIG. 5 is a block diagram presenting a object architecture 
of a service switching exchange for the telecommunication 
system. 
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FIG. 6 shows the service control facility SCP1 with 
several servers SERV and REP that are formed on top of an 
object infrastructure CORBA ORB in an object oriented 
environment CORBA. 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS 

FIG. 1 shows a telecommunication system TS with an 
telecommunication network KN1, a subscriber terminal T 
assigned to a subscriber A, a communication network KN2 
and two service control facilities SCP1 and SCP2. 

The telecommunication network KN1 is for example a 
telephone network. It is also possible that this network is a 
data network or a communication network for mixed data 
speech and video transmission. 

From the exchanges of the network KN1 two special 
designed exchanges SSP1 and SSP2 are shown. These 
exchanges are service switching exchanges that contain a 
20 service switching functionality SSP To these exchanges 
service request calls from the subscriber of the network are 
routed. When such a service switching exchange receives 
such a service request, it sends a corresponding request via 
the network KN2 to one of the two service control facilities 
25 SCP1, SCP2. The service is then provided under the control 
of the respective one of the service control facilities SCP1 
and SCP2. 

Each of the service control facilities SCP1 and SCP2 
provides one or several services S and realize a service 
30 control function. 

The communication network KN2 is preferably a data 
network, especially according to the SS7 signaling protocol. 
It is also possible that this network is a LAN (Local Area 
Network), a MAN (Metropolitan Area Network) or an ATM 
35 (Asynchronous Transfer Mode) network. 

Preferably, the service switching exchanges SSP1, SSP2, 
and the communication between them and the service con- 
trol facilities SCP1, SCP2 are designed according to the 
^ Intelligent Network Architecture (according to the service 
switching point and according to the communication 
between the service switching point and the service control 
point), described for example in the ITU-T Q.1214 Recom- 
mendation. 

45 If a user wants to start an service S, he dials a specific 
number for that service. The local exchange will route this 
call to the nearest service switching exchanges and this will 
trigger the service switching functionality SSP to start the 
service. This is done by sending a request to the SCP to start 

50 executing a Service Logic Program (SLP). An SLP is 
specific for each service, it will instruct the network on how 
to handle the service. It will execute service logic, statistic 
logic, database logic, charging logic, etc. It will also provide 
instructions for the switch (e.g., create the second leg of the 

55 call) and Intelligent Peripherals (IP) (e.g., announcement 
machines). A protocol according to the Information Net- 
working Architecture (INAP) protocol is used for this, and 
INAP messages are transported in TCAP messages between 
the SCP and SSP. 

60 When designing a distributed application, first the pos- 
sible system components to be distributed are identified (i.e., 
what the objects of the system are and how they will be 
grouped into larger objects that will be distributed). 
The breaking down of the SCP into objects offers some 

65 possibilities. FIGS. 2 to 3 depict these organized into dif- 
ferent architectures. All state information for handling one 
call was kept together and that all needed data was organized 
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into objects. So, one possibility for SCP objects is a script 
object that executes the service logic for one call and an 
object per data object. 

The values of the data objects are kept in a database, so 
having data objects that hide the use of a database is 5 
preferable (i.e., certain independence on the database). The 
catch lies in the fact that making these objects CORBA 
objects gives us a considerable overhead when methods 
(e.g., to read or write attribute values) are called on them. So, 
the system performance would become unacceptable. 3° 

The script object could be decomposed into a service 
execution engine and an SIB graph. So, SIBs could become 
distributed objects too. If database objects are distributed, 
this offers the possibility to execute an SIB on the machine 
where the particular data object resides. We can envisage a 15 
scheme where there is a control entity (a script) that executes 
SIBs remotely (possibility of having more overhead) or a 
scheme where control is passed from SIB to SIB. This trade 
off between getting the data and running a script on one 
machine and running parts of a script (SIBs) where the data 20 
resides is certainly worth investigating. 

The SSP's main functionality is to provide a hook 
between the call processing and the IN system. An SSP 
server must at least have an object that bridges between the 
normal Call Control Function (CCF) and an object that 
bridges between the Switching Function (SF). Also an object 
that bridges between Specialized Resources (SRF) (e.g., 
announcement equipment), seems to be obvious. In FIG. 5, 
these objects are depicted as a Switching Control, Call 
Control and Special Resources Object. We also need an 
object, Call Handler (CH) that interlaces with the SCP and 
the other objects in the SSP. There are two possibilities: there 
will be only one that handles all calls, or several, each 
handling one call. If we have several, existing only for the 
duration of the call, we also need a corresponding factory 
object to control the lifecycle of these objects. 

In the following is given the architecture of an SSP server 
on CORBA. For the Switching Control, Call Control and 
Special Resources objects we could have two approaches. In ^ 
the first approach they are only interface objects between the 
proprietary Application Program Interface (API) of existing 
software. In the second approach they would control the 
hardware directly, what implies providing a CORBA inter- 
face to Switching Control, Call Control & Special 45 
Resources. In theory this would be the best solution, since 
the approach would give an overall consistent software 
architecture, in this case special IDL (Interface Definition 
Language) adapter interfaces have to be designed. 

ASMP (Simple Management Protocol) is responsible for 50 
service control and monitoring. In order to be able to control 
services, the SMP does not need to be a DPE object. What 
is needed is that the objects that are controlled (e.g., script) 
provide an interface to do so. For monitoring we need an 
SMP object that is able to receive 'events' from the objects 55 
that are being monitored. In our research prototype we 
defined and implemented a trace control as an example on 
what is possible as management functionality on the SCP. 

In the previous section we have described a number of 
possibilities for CORBA objects in an IN Architecture. In eo 
this section we will group certain of these CORBA objects 
into a specific architecture. The sequence of the architectures 
can be seen as a possible evolution scenario, starting from 
current day's service provisioning, especially IN, products. 

The basis of the first architecture is the usage of a 65 
distributed database for data distribution and CORBA dis- 
tribution for distributed SCP. This architecture is designed to 



25 



30 



35 



interface with existing SSPs, so the SSP is not a CORBA 
object. Since this architecture was used to implement a 
research prototype, we elaborate on it more than the others. 
FIG. 2 depicts the architecture. 
The basic components in the architecture are; 
the script: a CORBA object that handles exactly one call 
the SLI (Service Logic Interface), a CORBA object that 
handles a TCAP dialogue for, and interfaces with the 
SSP. 

the distributed DB. 

Existing IN service scripts can encapsulated in Script 
objects. 

A Script object also contains the Service Data and Call 
Context related to a particular call, and one Script object is 
instantiated per call. The interface of the Script object 
contains operations that represent the TCAP messages that 
the Script receives during its execution. 

A special Service Logic Interface (SLI) object receives 
the #7 messages from the SSP and dispatches them to the 
corresponding script object instantiation, using the ORB 
services. The interface of the SLI object contains the TCAP 
messages that can be sent to it. One SLI object is instantiated 
per call. 

Since the Script and SLI objects exist only during the 
lifetime of a call corresponding factory objects are used to 
create and destroy them. Data objects are not CORBA 
objects, they are implemented as C++ objects. This approach 
hides the use of a particular database from the service logic. 

It is possible to use as database for example Oracle, 
SQLNET or ObjectStore. The SMP has not be considered; 
we could have used the proprietary mechanism to send 
status information to it, or defined it as a CORBA object with 
an appropriate IDL interface. 

However as an example on what is possible, its easy 
possible to design and implement a small trace control 
system; each server has a tracer object, the trace control part 
of the SMP can call methods to turn traces on particular 
implementation objects on and off. The SMP also manages 
the database (using SQLNET). 

A script and a SLI are CORBA objects, how they are 
distributed over servers is a deployment issue. A CORBA 
server is a process running at a particular node in the system. 
There is one SLIServer in the system that interfaces with the 
SSP. It has one CORBA object, the SLIFactory, that is 
always present when the server is running. 

The main purpose of this object is to create new SLI 
objects when new calls are started (when a TCAP dialogue 
is opened). The SLIServer is deployed in the node that has 
the #7 hardware and software installed. The system can have 
a number of ScriptServers, one per available node. 

This server also has a factory object, that exists during the 
lifetime of the server itself. This factory object is registered 
in the CORBA Naming service, so that an SLI can find it. In 
this way service logic distribution is facilitated. Adding 
more processing power to the system just means installing 
the new machine, running the ScriptServer on it, and the 
next time the SLI looks for a ScriptFactory a new possibility 
is available. The same mechanism also provides some 
reliability, when a machine goes down for some reason, the 
SLI will simply not get a reference to that ScriptServer any 
more. Note that the ScriptFactory is also to best candidate to 
put a management interface on (e.g., to change the service 
characteristics), since it is always available as long as the 
server is running. 

The interface between SLI and Script is defined to be 
asynchronous and in terms of TCAP primitives (BEGIN, 
INVOKE, RESULT, . . . ). This option is advantageous, since 



09/17/2003, EAST version: 1.04.0000 



US 6,201 

7 

one of the requirements is to reuse existing IN product 
software. Another option is to define this interface in terms 
of INAP primitives. 

The difference between a CORBA object, a (CORBA) 
server and a process must be clear. A CORBA object 5 
implements an interface and runs within a CORBA server. 
The CORBA server itself is one process that runs on a host 
(or node). This definition is important for the relation 
between a script and a call. In the current ALCATEL IN 
product implementation a script is a process that handles 10 
different calls, and keeps a different call context for each of 
those. This is done for performance reasons, starting up a 
separate process (script) for each call takes some time. 

We could adapt a similar approach (one script handles n 
calls) in these architectures, but the fact that a script has 15 
multiple contexts is not that clean and it is possible to deal 
with the performance issue by having a CORBA server with 
multiple scripts (each handling one call). So, it is better that 
in this architecture, a host can run one or more CORBA 
servers, each running different script objects that each 20 
handle a specific call. 

The CORBA server is similar to the script in the current 
IN product, but the problem of handling multiple contexts is 
shifted from the application programmer to the CORBA 
platform. 25 

A step further in this sequence of architectures, as second 
architecture, is to break down the script object into its 
components. As known, IN services are designed as a 
number SIBs that are nodes in a service logic graph. The 
execution of the script means executing SIBs and moving to 30 
the next SIB depending on data and responses coming from 
the SSP. Instead of designing this as a monolithic piece of 
software (from the SCE), it could be designed in terms 
cooperating SIBS. As known, the IN capability set 1. SIBs 
are not sufficiently defined to used them as they are. This 35 
resulted in IN platform providers having their own set of 
SIBs derived from the standard and software from SIBs is 
not reusable among platforms. 

When SIBs are defined as CORBA objects this situation 
could be broken and service providers would be able to 40 
design their own services, reusing existing SIBs (source 
code). 

Having SIBs as independent CORBA objects offers the 
possibility to execute the SIBs in different places. Instead of 
getting the data (using a distributed database, or using 45 
CORBA objects) to the place where the script or SIB is 
executed, we could start the SIB on the machine where the 
data is located. This brings benefits. We can envisage a 
scheme where there is a control entity (a script) that executes 
SIBs remotely or a scheme where control is passed from SIB 50 
to SIB. 

A third architecture breaks with traditional IN product in 
the sense that it also makes the SSP a CORBA object. In the 
previous architectures, for reliability reasons, it is still 
necessary that CORBA servers are deployed on machines ss 
that are interconnected on a reliable LAN. In practice, with 
the current DPE implementations (TCP/IP) this means put- 
ting the machines in the same location. This technology 
restriction prevents putting the SSP on the (Distributed 
Processing Environment), since in practice SCP and SSP 60 
sites are located on different places. However, technology 
evolves and DPE providers (e.g., IONA) are looking into the 
possibility of porting their product to other transport 
protocols, e.g., #7 links for telecommunication purposes. 
When this happens the step to making the SSP a CORBA 65 
object is not that big. In this case, the SLI object would not 
be needed anymore, since the SSP object could take over its 
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role. When a call is started it gets a reference to a Script- 
Factory and asks to create the script object itself. It could 
then communicate with this object directly. Also the lan- 
guage used in this communication (INAP encapsulated in a 
TCAP based interface) can be simplified. This interface 
could be defined in terms of INAP primitives (e.g., provide_ 
instruction(args), join(args)). This would improve (simplify) 
the system design and implementation, since the TCAP layer 
disappears for the application programmer. One could say 
that when CORBA is used, the application programmer must 
only be concerned with the application layer of the 
communication, not with the session layer (when TCAP is 
used). 

The final step would be to extend integrate a terminal (as 
proposed by TINA (Telecommunications Information Net- 
working Architecture)). This would mean a major change in 
user equipment. However this change is not infeasible if we 
consider the fact that more and more users get connected to 
the internet over their telephone lines. And the technology 
needed to have the DPE extended to the terminal is similar 
to this. The benefit of this would be that the terminal to 
network protocol could become much richer than just pass- 
ing DTMF tones as numbers. 

The above described architecture provides a solution to 
make especially IN platforms more scalable. Since inter- 
working with and evolution from existing products is impor- 
tant we presented a sequence of architectures that can be 
seen as a possible evolution scenario. 

FIG. 6 shows the service control facility SCP1 with 
several servers SERV and REP that are formed on top of an 
object infrastructure CORBA ORB in an object oriented 
environment CORBA. 

The different servers runs on different processing nodes 
PROZ1 and PROZ2. 

Each service that is provided by the SCP1 is implemented 
by one or many servers SERV. Each call to the service is a 
single CORBA object managed by one of the corresponding 
servers SERV through a factory. SSP1 and SSP2 has access 
to several servers SERV on top of the CORBA ORB. That 
is, as if they have access to several service control function 
SCPs. To provide the link a service repository server REP is 
designed. 

Upon request for a new service session, SSP1 accesses the 
service repository server REP to find an available service 
server SERV to execute the service session. 

Input information to the service repository server is made 
of the IN service name and a service session key. The 
matching object reference of the service factory is returned 
by the service repository server. 

A service server is registered into the service repository 
based on a constraint on the session key. Thus, a key 
definition language has been defined in offer to process the 
key definition when registering a new server, and process the 
key when the SSP performs a query. 

As an example an implementation procedure according to 
the architecture 3 is described in the following: 

A Credit Card Calling service which existed for the UNIX 
based IN Release existing Alcatel product is to be imple- 
mented. The Credit Card Call service is a "typical" IN 
service and allows a call from any terminal to be billed to a 
particular card number. To set up that call, the user has to 
enter a card number, a PIN code and the destination number. 
If the entered data is correct, the call is completed to the 
destination address and charged to the user's card. 

An SSP simulation stub was used to generate the TCAP 
dialogue for the Credit Card Call. The SSP stub is a CORBA 
object that sends and receives the same TCAP messages that 
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an SSP would. The SSP stub is capable of simulating It should be noticed that existing signaling networks were 

different call scenarios, can generate different call loads and never dimensioned to support the sort of traffic which will be 

can repeat a scenario an arbitrary number of times. exchanged by CORBA nodes. However, there is a potential 

Another general issue for the use of CORBA in an IN benefit in this approach by exploiting the fault tolerant 

oriented service provisioning architecture is the interwork- 5 nature of the SS7 network. 

ing of CORBA-based IN with legacy IN applications. ^ ^ ncre & thc choice of 557 protocol access 

This mterworking can be achieved with the use of Adap- level for this ^Won. 7^ two principal choices are TCAP 

tation. It is related to the way a CORBA based infrastructure am j seep- 

can communicate with the legacy of switching systems, GIOP at TCAP level- 

^Ire^wo approaches possible: 30 ,l should bc to u lf ™ *\ r . G I° P 

1) Definition of an Adaptation Unit which is an application niessagcs since IT is essentially a ROSE-like service. Ser- 

level bridge that provide the mapping of SS7 and TCAP vices which make use of TCAP must define their °P erati0ns 

primitives into IDL invocations. This approach is similar usin S ASNA modules. It is envisaged that ASN.l macros 

to one taken by the XoJIDM group (Joint Inter Domain would used to define the operation set: Request, Reply, 

Task of X/Open) for the CORBA/CMIP gateway. The 15 CancelRequest, LocateRequest, LocateReply, QoseConnec- 

result of their works can be reused especially the static 11011 and MessageError. These operations correspond to the 

mapping of GDMO/ASN.l to IDL interfaces (GDMO is GI0P Primitives. The gateway would be responsible for 

an acronym for "Guidelines for the Definition of Managed converting CDR format, of the form used by GIOP, into a 

Objects," and ASN.l stands for "Abstract Syntax Nota- form transportable using ASN.l types (possibly as an 

tion One") 20 °P ac l uc buffer with BER encoding). 

In order to minimize the impact on existing systems, u ™? * P?™* m P™«P le L t0 ™ T( ^ P 45 

CORBA should provide framework services and tools the basis for the ^ l0? ^ lt 15 not smtablc because of: 

in order to achieve this mapping. The availability of tne complexity of the implementation, 

such framework will allow interworking of CORBA- the overhead incurred in by the TCAP layer in addition to 

based IN with a variety of existing hardware such as 25 basic transport 

SCI^ and HLRs. trje asynchronous nature of the protocol. 

Such application level bridge should be characterized by ESIOP at SCCP level: 

high availability and high performance without being a The other choice for implementing the SS7 ESIOP is at 

bottleneck for a distributed system. However for the 3Q the SCCP level. The SCCP provides services corresponding 

required real-time performance, this is an intermediate to the OSI-RM network layer functionality. It can operate in 

solution towards full IN CORBA-based systems. both connection-oriented and connectionless mode. It 

This approach would involve building an IDL interface to should bc feasible to use the SCCP to transport GIOP 

represent application level protocols such as MAP and messages although the ESIOP code may be required to 

INAP and others which are based on the TCAP layer. 35 perform its own transport layer functions (e.g., end-to-end 

The TCAP layer provides a 'ROSE-like' asynchronous flow-control and segmentation/re-assembly). It should be 

RPC service over the SCCP layer. And basing the possible to address CORBA nodes using the "Global Title" 

bridge on TCAP will exclude the use of circuit related mode of SCCP addressing. It would appear that using SCCP 

signaling protocols such as ISUP and TUP from the as the basis for an ESIOP for the SS7 network would be the 

solution. ^ best approach, 

like in the XoJIDM approach, there should be a static The following requirements are advantageous for an 

translation of the INAP/TCAP specification to IDL object oriented environment for an infrastructure in which a 

interfaces which will be done by a dedicated compiler. service session object interacts (described by hand of the 

Thus, any INAP dialect can be converted to appropriate CORBA environment): 

IDL interfaces. These applications level bridges would 45 In terms of functional requirements, CORBA should 

implement these IDL generated interfaces and dynami- provide: 

cally perform conversion between IDL-derived types asynchronous Invocation model and support for group 

and their ASN.l equivalents. communication in the ORB; 

CORBA nodes using the protocol specific bridges would proper hooks for extending the ORB with security, trans- 

generally run two servers, one each for processing 50 action and replication mechanisms; 

outgoing and incoming invocations. Since TCAP is a nodc management minimaI object lifecycle facilities; 

connectionless service the gateway will have to main- ... 

. • . # • j . „ . u • J . 1 a time service and native monitoring facilities for captur- 

tain state m order to match invocations to responses and , 4 . , , P Y 

■ r ing both computational and engineering events; 
exceptions. 

2) Usage of SS7 as an Environment Specific Inter-ORB 55 su PP ort for multithreading with flexible event-to-thread 
protocol (ESIOP): mappings. 

Apossible solution is to map the CORBA GIOP (General ^ non-functional requirements of CORBA are con- 

Inter-ORB Protocol which makes requests or returns cerned 

replies between Object Request Brokers) on top of SS7 identifying the level of salability and object granularity 

or to build a new Extended protocol (ESIOP) on top of 6 0 that lhe ORB should meel in ^ IN °° ntGX ^ 

the SS7 layers. identifying the performance level that the ORB must 

The ESIOP solution would essentially use an SS7 achieve in terms of latency, throughput, etc.; 

protocol-as a transport for the GIOP protocol. CORBA providing a predictable ORB core by instrumenting and 

objects would be visible across the SS7 network in documenting the time behavior of the platform; 

exactly the same manner as they would be across the 65 reliability which denotes requirements that define accept- 

Internet with the CORBA HOP. This would allow as able behaviors for the distributed applications in the 

ORB to use existing SS7 infrastructure as transport. presence of hardware and software failures. In this case 



09/17/2003, EAST Version: 1.04.0000 



US 6,201 

11 

two types of reliability can be identified; the integrity 
state and the availability; 
manageability which denotes requirements that enable 
ease of development, deployment and operation for 
complex applications. In this case maintainability, (re) 5 
configurability and extensibility of CORBA applica- 
tions. 

An asynchronous Invocation model commonly used by 
IN applications. Thus, asynchronous and optionally isoch- 
ronous invocation model is required with the ORB. The JQ 
requirement here is a client side programming model which 
potentially supports a lightweight asynchronous communi- 
cation mechanism incorporating a mandatory callback (or 
ORB "upcalF' type mechanism) and optionally a "Futures" 
type programming model. 

For the same object, both asynchronous and synchronous 15 
models should co-exist. The maximum concurrency level is 
defined in the configuration (e.g., QoS parameters), and has 
to be controllable, with the possibility of queuing the request 
or returning an exception. 

A basic fault detection support should be provided by the 20 
ORB runtime for any object which needs it. This can be done 
by a timer which is implicit set and managed in the client 
process. 

Flexibility and scalability: 

The ORB should be able to support applications handling 25 
a large number of objects and should be able to support 
many simultaneous connections to remote objects. 

The memory cost of an unused remote interface reference 
in a given capsule (i.e., Unix process) should be of the order 
of a standard language pointer. 30 

A typical telecommunications environment comprises 
objects of very different granularities in both space (memory 
size) and time (object lifetime and duration). A scalable 
ORB should support objects at different levels of granularity, 
and minimize the overhead associated with the handling of 35 
small and volatile objects and of connections to remote 
objects. 

To achieve some of the ORB fault-tolerance and 
reliability, the CORBA object model could be enhanced to 
support groups of objects or globally known as group 40 
communication such as those described 
Reliability and availability: 

To achieve the reliability requirements, the notion of 
replicated distributed objects can be introduced in CORBA. 
Thus the critical components of the application are imple- 45 
mented through replicated objects. This replica management 
can be handled automatically by the ORB such that clients 
interacting with a given server object is not aware if it is 
replicated or not. The degree of replication can be deter- 
mined by the desired level of reliability which can be 50 
measured with the number of maximum number of concur- 
rent failures; the nature of the failure which can be typed 
(malicious or benign); and the type of reliability property 
being sought such as integrity or availability. High avail- 
ability or Fault Tolerance capabilities should be provided by 55 
CORBA for distributed IN systems in order to ensure the 
same robustness as current IN systems. 

Timeliness requirements can be also achieved by the 
replica service. For example, applications that need to have 
bounded and predictable delays will be implemented 60 
through replicated objects. Each replica is able to process 
locally all of the methods defined for the object. In the 
absence of failure, a client can use any of the responses to 
a method Invocation as its result, (the invocations in this 
case is perform synchronously). 65 

To achieve this, the ORB will have a modular structure 
allowing the implementation of different profiles, depending 
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on application or services requirements. These profiles gjve 
an abstraction of the resources provided by the underlying 
operating system. One of the ORB module will be a failure 
detector which is at the lower level of the ORB structure. 
And a response Invocation delay beyond a certain threshold 
are classified as failure. Thus, the client is able to trade off 
reliability for timeliness, the shorter the threshold, the tighter 
the bounds on delays. By replicating an object in a sufficient 
number of times, the client is able to meet both timeliness 
and reliability requirements simultaneously. 

Here, we have identified a requirement for a replication 
service with correctness, safety and liveness properties; and 
a failure detector module which is part of the ORB core. 
Performance: 

Performance of IN are measured in number of calls per 
second for service nodes and intelligent peripherals; and 
number of transaction per second for signaling control point. 
These calls and transactions may involve multiple messages 
exchanged between an SSP and the Intelligent Layer. 

To obtain the actual performance of legacy IN systems, 
real-time performance of the ORB is required for the use of 
distributed processing in IN systems as well as its distribu- 
tion on a geographical scale (non centralized IN systems). 
To achieve better performance for IN distributed systems, 
the ORB call overhead should be reduced, and the perfor- 
mance level that the ORB must achieve in terms of latency, 
throughput, etc. should be defined and documented. 

What is claimed is: 

1. A method for providing at least one service to users of 
a telecommunication network, in which method service calls 
requesting the execution of the service for an respective one 
of the users are routed to a service switching exchange of the 
telecommunication network or are respectively routed to one 
of several service switching exchanges of the telecommu- 
nication network and in which method a corresponding 
service request is sent by the respective service switching 
exchange, that has received the respective service call, to a 
service control facility, characterized in that the service 
request is routed to a particular one of a plurality of servers 
of the service control facility, which are formed on top of an 
object infrastructure within an object oriented computing 
environment, that the particular server acts as service reposi- 
tory server and determines another one of the plurality of 
servers that is available and able to execute the control of the 
service for the respective service call. 

2. A method as claimed in claim 1, characterized in that 
different services are provided by the service control facility 
and that a service logic function for each of these different 
services is implemented within one or several of the servers. 

3. A method as claimed in claim 1, characterized in that 
the particular server determines an object reference of a 
service factory object that creates a service session object 
which is able to control the execution of the service for the 
respective service call, said factory object being an object 
which provides the function of creating a specific kind of 
object. 

4. A method as claimed in claim 1, characterized in that 
a service session object, which manages a service session, is 
managed by one of the servers through a factory object. 

5. A method as claimed in claim 1, characterized in that 
for each service request one service session object, which is 
able to interact and communicate via an object infrastructure 
with other objects in a object oriented computing 
environment, is created and the respective service session 
object controls the execution of the service for the respective 
service call. 

6. A method as claimed in claim 1, characterized in that 
the particular server receives as input data a name and a 
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service session key and returns a matching object reference 
of a service factory object, wherein said session key is a key 
used for just one message or set of messages. 

7. A method as claimed in claim 1, characterized in that 
the other servers are registered into the particular server 
based on a constraint of a session key. 

8. A method as claimed in claim 1, characterized in that 
the particular server performs load balancing between the 
servers that implementing the same service. 

9. A method as claimed in claim 1, characterized in that 
the or each service switching exchange of the telecommu- 
nication network communicates with the or each service 
control facility according to the communication protocols of 
the Intelligent Network Architecture. 

10. A method as claimed in claim 1, characterized in that 
the plurality of servers is formed on top of CORBA object 
infrastructure. 

11. A method as claimed in claim 1, characterized in that 
the creation of each service session object is managed 
through a factory object. 

12. A method as claimed in claim 7, characterized in that 
the factory object implements a life cycle policy for the 
service session object, wherein the factory object creates the 
service session object and destroys the service session object 
when the service session object's life cycle is over. 

13. A method as claimed in claim 7, characterized in that 
the factory object implements a creation on demand life 
cycle policy for the service session object. 

14. A method as claimed in claim 7, characterized in that 
the factory object implements activation on demand life 
cycle policy for the service session object. 

15. A method as claimed in claim 1, characterized in that 
the service session object has, as its interface definition, 
TCAP mapped over IDL. 

16. A method as claimed in claim 1, characterized in that 
the service session object receives directly its own message 
invocations. 

17. A method as claimed in claim 1, characterized in that 
the service session object receives I NAP messages from the 
or each service switching exchange as message invocations. 

18. A method as claimed in claim 1, characterized in that 
each service session object runs in its own thread. 

19. A method for provisioning the execution of service 
logic functions within a service control facility of a tele- 
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communication systems, where service requests, that 
request the execution of a service logic function, are 
received by the service control facility from at least one 
service switching exchange of the telecommunication 

5 system, characterized in that the service request is routed to 
a particular one of a plurality of servers of the service control 
facility, which are formed on top of an object infrastructure 
within an object oriented computing environment, that the 
particular server acts as service repository server and deter- 

10 mines another one of the plurality of servers that is available 
and able to execute the respective service request. 

20. A service control facility for connecting to one or 
several service switching exchanges of a telecommunication 
network, where the service control facility contains means 

is for receiving service requests, that request the execution of 
a service for a user of the telecommunication network, from 
at least one of the service switching exchanges of the 
telecommunication network, characterized by containing a 
plurality of servers, which are formed on top of an object 

20 infrastructure within an object oriented computing 
environment, containing means for routing the service 
request to a particular one of the service control facility, and 
containing the particular server acting as service repository 
server and determining another one of the plurality of 

25 servers that is available and able to execute the respective 
service request. 

21. The service control facility according to claim 16, 
characterized by containing a variable number of processing 
nodes processing the plurality of servers. 

30 22. A server node for a service control facility connected 
to one or several service switching exchanges of a telecom- 
munication network, where the server node contains means 
for receiving service requests, that request the execution of 
a service for a user of the telecommunication network, from 

35 at least one of the service switching exchanges of the 
telecommunication network, characterized by that the server 
node is formed on top of an object infrastructure within an 
object oriented computing environment, and containing 
means for determining another one of a plurality of server 

40 nodes which are formed on top of the object infrastructure 
within the object oriented computing environment, that is 
available and able to execute the respective service request. 

* * * + * 
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[57] ABSTRACT 

A tdecommuoications system infrastructure that facilitates 
easy insertion of feature software into existing such tele- 
communications systems and easy integration of the new 
calling features and their implementing software with exist- 
ing features and their software. The infrastructure comprises 
the Lucent Technologies MMCX multimedia communica- 
tions server (160) and imddlcware-compUant communica- 
tions endpoints (101-102) executing the Lucent Technolo- 
gies MMCX communications middleware (111-112). 
Feature-implementing software has a modular client/server 
construction, with feature managers (server modules. 300. 
350) executing on the MMCX server and feature adminis- 
tration agents (client modules, 303*453, 304-354) execut- 
ing on the endpoints. The infrastructure provides a context 
service (120) and a context API (121) for registering an 
instance of a feature manager (a user policy, 301-302, 
351-352) for each user upon that user becoming entitled to 
the feature, an administration API (360) for communications 
between feature managers and feature administration agents 
on the user's endpoint to customize the user's user policies 
for the user, and a context (a cyberspace meeting room. 200) 
and the context API for involving the user policies of users 
who are parties to a call in the call and for communicating 
call-related events to feature servers and other service- 
implementing software. Call-related events are passed to 
user policies involved in the call, and they are given a chance 
to react to the events by allowing or rejecting the events. 
Interactions between features are managed by having feature 
managers register at different priorities with the context 
service; higher-priority modules are serially given an oppor- 
tunity to allow or reject events before lower-priority mod- 
ules. 

10 Claims, 5 Drawing Sheets 
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ARRANGEMENT FOR FACILITATING 
PLUG-AND-PLAY CALL FEATURES 

TECHNICAL FIELD 

This invention relates to stored-program-controUcd com- 
munications systems, including multimedia communica- 
tions systems. 

BACKGROUND OF THE INVENTION 

Traditionally, adding calling features to switching-system 
(e.g.. central office or PBX) control software has required 
modifying existing feature programs while paying careful 
attention to interactions between existing features and the 
new features. For example, implementing call-center fea- 
tures on a PBX that already provides call-forwarding and 
call-coverage requires careful coordination between the two 
sets of features, ensuring that calls are handled correctly 
when a call-center agent enables call-forwarding or call- 
coverage. In a miiltfmn* 1 * 11 telecommunicaions system where 
users are presented with graphical user interfaces, the need 
to provide new user interfaces to control new features poses 
an additional problem: in order for the endpoint user- 
interface and the server feature-software to communicate, 
the endpoint-to-scrver protocol generally needs to be 
updated. 

The above-mentioned constraints present an imposing 
bonier to developers who are responsible for continuing 
maintenance and upgrades of the features. These constraints 
present an even-more imposing barrier to the development 
by third-party vendors of new features or of new versions of 
existing features. Third parties generally have neither the 
interest nor the capability to modify the tdecommunications 
system software in order to make their feature software fully 
compatible therewith. Consequently, the telecommunica- 
tions system owner is dependent exclusively on the system 
manufacturer for the feature set and feature upgrades of the 
system. 

SUMMARY OF THE INVENTION 

This invention is directed to solving these and other 
problems and disadvantages of the prior art Generally 
according to the invention, there Is provided a telecommu- 
nications system infrastructure that facilitates easy insertion 
of feature software into an existing said telecommunications 
system, and easy integration of the new calling features and 
their implementing software with existing features and their 
software. 

Specifically according to one aspect of the invention, a 
call -control apparatus that executes feature-implementing 
software, wherein each call feature is implemented as a 
server p iogt am and a cooperating client program, has the 
following elements. An arrangement (illustratively a context 
service) for registering for a user an instance (illustratively 
a user policy) of a server program that implements any call 
feature, in a same manner as any other in s tanc es of any 
server p rogr a ms that implement any call features, substan- 
tially at any time during operation of the call-control appa- 
ratus to provide the call feature for the user. In other words, 
the registration mechanism is identical for all feature- 
implementing programs, and operates dynamically. An 
administration interface (illustratively an application pro- 
gram interface, or API) for communicating information 
between the server program and a cooperating said client 
program used by the user, in a same manner as between any 
other client programs and any server programs that impfte- 
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ment any call features, to customize the instance of the 
server program for the user. In other words, the administra- 
tion interface is identical for all feature-implementing pro- 
grams. An arrangement (illustratively a context, which is a 
5 cyberspace meeting room, along with the context service) 
for involving the instance of the server program in a call to 
which the user is a party, in a same manner as any other 
instance of any server programs that implement any call 
features, to provide the feature to the call. In other words, the 
mechanism for involving feature-iinplementing programs in 
10 calls is also identical for all features. 

The above-characterized call-control apparatus provides 
all the interaction that is needed between feature- 
implementing programs as well as between feature- 
implementing programs and other service- irnpl e rncnt i ng 
15 programs. Consequently, substantially any feature- 
implementing program that complies with the registration 
and conforms with the administration and in-call- 
invofvement communications schemes may be added to and 
used in the apparatus; the call-control apparatus automati- 
20 cally effects integration of any such new feature- 
implementing program into the existing environment. 

Preferably, interactions between feature-iinplementing 
programs are managed efficiently by having priorities asso- 
ciated with the individual programs. Each instance of each 
25 server program has a priority associated therewith, and the 
arrangement for involving feature-implementing programs 
in includes an arrangement (illustratively a context 
service and its context API) that responds to occurrence of 
a request for service (referred to herein as "an event**) in the 
30 call by giving instances of server programs that are involved 
in the call each a chance to respond to the event in an order 
of their associated priorities. In other words, higher-priority 
programs are given an opportunity to approve or reject 
events before lower-priority programs. The system designer, 
administrator, or users are allowed to change the relative 
35 priorities of the feature-implementing programs and thereby 
control how features interact with each other. For example, 
it allows the adininistrator to specify whether call coverage 
is invoked for a call before call forwarding, or vice versa. 
Preferably, the arrangement for involving feature - 
40 implementing programs in calls includes a second interface 
(illustratively also an APL referred to herein as the context 
API) for orrTm Min '*» riw g *wnts between a plurality of server 
programs that are involved in the call, in a same manner as 
between server programs that are involved in any other calls. 
45 In other words, the second communications interface is also 
identical for all feature-implementing programs. The 
arrangement responds to receipt through the second inter- 
face of a proposal of an event from a first server program — 
illustratively the originator of the proposed event — that is 
50 involved in a call by sending a request for approval of the 
event through the second interface to the first server program 
and also to other (at least one) second server programs that 
are also involved in the call. The arrangement the n responds 
to receipt through the second interface of approval of the 
55 event from both the first and the second server programs by 
sending notice of the approval of the event through the 
second interface to both the first and the second server 
programs — and preferably to all server programs that are 
involved in the call— to cause the event to be effected. The 
60 arrangement preferably further responds to receipt through 
the second interface means of rejection of the event from 
either the first or the second server program by forbearing 
from sending an approval of the event to both the first and 
the second server programs to prevent the event from being 
65 effected, and preferably also sends the rejection through the 
second interface to the first server program to abort the 
event 



09/30/2003, EAST version: 1.04.0000 



5,717, 

3 

Specifically according to another aspect of the invention, 
a method of controlling calls in an apparatus wherein each 
call feature is implemented as a server program and a 
cooperating client program and which executes the client 
and the server programs, comprises the following steps. In 3 
response to a user becoming entitled to a call feature, an 
instance of the server program that implements the call 
feature is registered for the user, in a same manner as any 
other instance of any server programs that implement any 
call features, substantially at any time during operation of 10 
the apparatus, to provide the call feature for the user. Then 
in response to the user using the client program, information 
is communicated between the server program and the client 
program through an administration interface, in a same 
manner as information is communicated through the admin- 15 
istration interface between any other client programs and 
any server programs that implement any call feature, to 
customize the instance of the server program for the user. 
Then in response to the user becoming a party to a call the 
instance of the server program is involved in the calL in a 20 
same manner as any other instance of any server programs 
that implement any call features, to provide the feature to the 
call. Plug-and-pliy feature capability is thereby effected for 
feature-implementing software. 

These and other advantages and features of the present 25 
invention will become more apparent from the following 
description of an illustrative embodiment of the invention 
taken together with the drawing. 

BRIEF DESCRIPTION OF THE DRAWING 30 

FIG. 1 is a block diagram of an illustrative multimedia 
communications system; 

FIG. 2 is a block diagram of a call-service model imple- 
mented by the system of FIG. 1; 35 

FIG. 3 is a block diagram of a call-feature model imple- 
mented by the system of FIG. 1, which embodies an illus- 
trative implementation of the invention; 

FIGS. 4 and 5 are functional flow diagrams of registration 
procedures of feature managers and their user policies of the 40 
model of FIG. 3; 

FIG. 6 is a functional flow diagram of a feature admin- 
istration procedure of a feature administration agent of the 
model of FIG. 3; 

FIG. 7 is a functional flow diagram of an event- 
negotiation procedure of a context and context members of 
the model of FIG. 3; and 

FIG. 8 is a functional flow diagram of a message-passing 
procedure of the context of the model of FIG. 3. 30 

DETAILED DESCRIPTION 

FIG. 1 shows one possible architecture of a multimedia 
communications system. The system comprises a plurality 
of communications endpoints 191-102 connected by com- 55 
munications links 103 with a communications server 100. 
The system of FIG. 1 can be, for example, a telephone 
system where server 100 comprises a miilrimrdia-cnabled 
switching system such as a Lucent Technologies Definity® 
G3 PBX, endpoints 101-102 comprise video workstations 60 
such as the NCR Vistium® stations, and links 103 comprise 
high-bandwidth telephone lines such as ISDN BRI lines. 
However, in this illustrative example, server 100 is assumed 
to be a multimrdia-serviccs server such as the Lucent 
Technologies Inc. MMCX multimedia communications 65 
exchange, endpoints 101-102 are assumed to be miiirimftHi* 
(including video) workstations, and links 103 are assumed to 
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be a local-area network (LAN) or a wide-area network 
(WAN). Server 100 and endpoints 101-102 are stored- 
program-controlled entities. As such, each includes a 
memory for storing control software, a processor for execut- 
ing the stored control programs, and input and output 
interfaces to the outside world, as is well known and 
understood in the art 

According to well-known software-system design 
principles, the control software 104 of server 100 and 
endpoints 101-102 is organized in a multi-layer hierarchy. 
At the lowest level in the software hierarchy, the control 
software of server 100 and endpoints 101-102 in this 
illustrative example comprises a conventional operating 
system 109— such as the Lynx® operating system— that 
includes conventional device drivers 108. Next in the hier- 
archy is a conventional networking and transport services 
layer 110 — such as the Transmission Control Protocol/ 
Internet Protocol (TCP/IP) — which provides the 
information-movement (Le.. control-signal and information- 
signal transmission) services between server 100 and end- 
points 101-102. Built on top of layer 110 is a middleware 
layer 1U. Middleware is a term for a software platform that 
provides network-transparent support for the development 
and implementation of network-based distributed-system 
applications (e.g., communicanons services). It is both an 
applications-development tool and a run-time environment 
It provides a distributed object-based computing infrastruc- 
ture including distributed object life-cycle management, 
network abstraction, and operating-system and transport- 
service vimialization. It therefore allows communications 
applications to be written independently of the resident 
operating system, the network transport the interworking 
algorithms, etc. It also supports a middleware services layer 
112 which provides common services that support various 
cominunications applications, such as services for session 
management, routing, event collection, service location, etc 
Implemented on top of layers 111 and 112 are applications 
113, e.g., specific communications services programs. 
Applications 113 communicate with layers 111 and 112 by 
means of application program interfaces (APIs) of layers 111 
and 112, and communicate with users and/or administrators 
via interfaces defined by an interfaces layer 114. In the case 
of endpoints 101-102, applications 113 illustratively com- 
prise a version of InsofVs Communique I™ collaboration 
software. 

Layers 111 and 112 illustratively comprise the commu- 
nications middleware software of the Lucent Technologies 
Inc. MMCX, heretofore known as CoMMware. Layer 111 
comprises the middleware platform, while layer 112 com- 
prises niioxfleware-compliant service components that make 
use of the middleware platform primitives to control calls 
and their different-media components and to supply calling 
features (like call-coverage and call-forwarding, for 
example.) The service components include service managers 
(servers) and service agents (clients). 

The middleware platform provides an infrastructure for 
bringing parties and multimedia services into communica- 
tions "contexts* which provide bases for negotiation of 
service parameters. Each communications session (eg,, a 
multimedia call) is represented by its own context The 
architecture provides support for customizable service nego- 
tiation and control software, called "policies", that allows 
application and service developers to meet a wide variety of 
product-and service-specific needs. 

In the model of communications that is presented by the 
middleware, all communications take place within a context 
and parties and services are associated with one another as 
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members within the context by a context service. The 
context service is somewhat analogous to Microsoft Corpo- 
ration's Windows™ system. Just as the Windows system 
distributes events that reflect a change in the applications * 
presentation environment to all applications running in that 
environment so does the context service distribute events 
which reflect a change in the communications context to all 
members of that context In addition to the event-notification 
mechanism, the context service also supports message- 
passing among context members, fox example, to enable 
negotiation of mterworking parameters between endpoints 
and servers with possibly-disparate capabilities. 

The middleware effectively provides a signaling overlay 
on top of the underlying network architecture, which overlay 
supports multiparty, end-to-end negotiation that facilitates 
the design of interoperable multimedia communications 
products and services. Middleware concepts of context 
virtual transport and trading aid in the provisioning of 
multi party, multimedia distributed communications in het- 
erogeneous environments. 

The model of communications that is presented by the 
middleware is shown in FIG. 2. The middleware facilitates 
bringing parties and services together in a "cyberplace". 
which is referred to as context 20#. A context server 2*1 
manages context 2#0 to/from which may be added/dropped 
the context members. Members may be parties and services. 
A logged-in user of an endpoint 101-112 who is a member 
of a context is referred to as a party (221-221) to that 
context A service is represented in a context 20# by its 
service manager 210-211. Parties and services are treated 
identically by context server 201, and are referred to simply 
as "members". All members in a context 200 are represented 
by a context agent facility 202. Each member of context 210 
is logically represented in context agent facility 202 by its 
own corresponding member context agent 213-206 (eg., its 
own virtual port on context agent facility 202). When 
context 200 changes as a result of members being added to 
or dropped from the context, context server 201 alerts all 
members* context agents 203-206, which in turn notify their 
corresponding members. When a new member joins an 
existing context 200, all members already In the context are 
similarly notified, and each has a chance to exchange some 
initial "get acquainted" messages with the new member and 
with other members that were already in the context In 
middleware, this is called "negotiation", since it is generally 
used to achieve a common ground for communications 
between the members (parties and services) in the context 

The middleware provides support for brokering in three 
ways. Pint the middleware includes trading service 124, 
which is a database system that can be used to locate 
services based on service characteristics. Services are con- 
structed in a client/server configuration, with programs that 
actually provide the services, called service managers 
210-211 (also call services, service components, resource or 
media servers, or resource or media managers), being 
located in MMCX server 100, and programs that obtain the 
services from service managers 210-211 on behalf of appli- 
cations in endpoints 101-102, called service agents 230-233 
(also called service clients, or resource or media agents), 
being located in endpoints 101-102. Service managers 
210-211 can register with trading service 124, giving their 
service attributes and capabilities. Trading service 124 pro- 
vides a query capability to enable service agents 230-233 to 
obtain identities of services (Le., of service managers 
210-211) that can meet the common needs of the parties in 
a context Secondly, specialized brokering services 132 can 
be written, which are servers themselves that can be brought 
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into a context A brokering service uses the generic nego- 
tiation ny* 1 *™*™ provided by the middleware to gather the 
service-related attributes of the parties in the context 
enabling it to bring other service managers 210-211 into the 

5 context that can meet their, perhaps diverse, needs. And 
finally, the middleware supports the development of implicit 
brokers which, as policies of context server 201, can exam- 
ine the attributes of the context and its members to bring 
services into the context This sort of broker might be used, 

1Q for example, to bring billing services into the context. These 
brokering mechanisms can also be used in unison. A spe- 
cialized broker may, for example, gather parties' attributes 
and formulate a complex query to trading service 124 to 
locate the right service. 

1S The middleware provides a framework for introducing a 
level of signalling and control for communications sessions 
that fits logically above the transport network. This means 
that software can be written to formalize communications 
that are required to set up calls. The middleware supports 

20 codification of the signalling used for service composition 
and separates it from that used for control of bearer channels 
and network connections. A member context agent 203-206 
of context agent facility 202 utilizes virtual transport to 
access underlying transport services for establishing a sig- 

25 nailing connection to a context server 201. which, in turn, is 
then able to establish signalling connections with other 
member context agents 203-206. Context agent facility 202 
utilizes a transaction protocol with context server 201 to 
create a context 200 for a communications session and to 

30 associate parties 220-221 and service managers 210-211 
with the context Integral to this transaction protocol, the 
middleware provides a foundation for negotiation among 
parties' service agents 230-233 and service managers 
210-211 which allows media-specific service agents 

35 230-233 and service managers 210-211 to agree on service- 
specific parameters regarding the communications session. 
The specific negotiation protocol as defined in common for 
a specific media service, is implemented in replaceable 
program entities (policies) which are bound to context 

40 transaction processing. 

While the communications model supports familiar com- 
munication system features (with parties and transport), 
more elaborate communications in which multiple parties 
and a rich array of services are added and removed dynami- 

45 cally are also supported naturally within the model. For 
example, a two-party voice call can be turned into a multi- 
party conference with a video and a multipoint shared 
application by adding additional parties, a video-connection 
service, and a shared-data soviet to the context Further. 

50 since the services in a context may be independent of one 
another, each can be added and removed at any time without 
affecting the others. These attributes of the model result 
from the concept of context and the fact that the signalling 
for bearer-channel connection-control and for establishment 

55 and control of the context are separate. 

A second example illustrates additional attributes of this 
model. If an interactive service (such as "800* -number 
video-catalog shopping) were desired, an endpoint would be 
able to request the service and negotiate the attributes of the 

60 service to conform to its own capabilities. But then, the 
service itself could request that required ancillary services 
be added to the context such as billing, order processing, 
and credit card authorization. This illustrates the fundamen- 
tal symmetry of the middleware architecture that provides 

63 parties and services with the same status in a context, thus 
allowing all members the full power of the context transac- 
tion protocol. 
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As shown in FIG. 1, the middleware is constructed as 
follows. There are six architectural elements to the middle- 
ware platform: 

Context service 120: The context service provides the sup- 
porting mechanisms for the middleware model of com- 
munications that provides a context for a communications 
session in which service providers and service users are 
treated as undifferentiated members with equal privileges 
and capabilities. Context service 120 is provided by 
interactions between a context server 201 that manages a 
context 200 and a context agent 202 that represents the 
members of the context Communications with context 
service 120 are effected through a context API 121. 
Context API 121 is available to both applications software 
and service modules. This means that, although policy 
modules will normally buffer applications from context 
transactions, negotiation, and service control, it is pos- 
sible for applications to directly react to and influence 
these activities. 

Naming service 122: A distributed naming database mat 
allows the middleware and middleware-based applica- 
tions to access transport addresses associated with a 
middleware identifier (CWID). Bach service manager 
210-211 and party 220-221 has its own CWID. The 
naming service performs two mappings: 1) a mapping 
from a CWID to a transport-independent address (a 
virtual transport address, or VTA), and (2) a mapping 
from a VTA to transport-dependent addresses and 
attributes. The attributes associated with each VTA illus- 
tratively consist of "attribute name; attribute value" pairs* 
where there is a fixed set of attribute names supported. 
Service agents 230-233 use the first mapping to get the 
VTA for a given party or service manager and then give 
the resulting VTA to virtual transport service 126, which 
calls on naming service 122 to perform the second map- 
ping in order to obtain actual transport addresses for 
establishing transport connections to these parties and 
service managers. Communications with naming service 
122 are effected through a naming API 123. 

Trading service 124: Trading in the middleware is service 
selection based on combined attributes of the members of 
a context Trading service 124 is a database that supports 
service registration and the ability to locate service man- 
agers 210-211 by required attributes. Trading service 124 
has the ability to satisfy queries from service agents 
230-233 that require it to find the "best match** of party 
attributes to service attributes. Service managers register 
with the trading database. Brokers can be developed in the 
middleware that use trading service 124 to find a best 
match for the collective needs of the members of a 
context Communications with trading service 124 are 
effected through a trading API 125. 

Remote object management (ROM) service 127: The ROM 
service is a simple object request broker (in the object- 
oriented programming sense). It uses virtual transport 
service 126 to allow object methods to be invoked 
remotely. ROM service 127 is available to both the 
middleware itself and to applications and policy modules. 
Policy modules may make use of ROM service 127 to 
establish out-of-context communications channels with 
peer or server policy modules. Applications make use of 
ROM service 127 to establish client-server connections. 

Virtual transport service 126: An abstraction of transport that 
presents a common model for a variety of communica- 
tions networks. The use of virtual transport enhances the 
portability of applications and services and their interop- 
erability in heterogeneous network environments. Each 
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entity in the middleware is given a virtual transport 
address (VTA) which allows addressing of and connect- 
ing to that entity in a oetweck-iodependent manner. 
In addition to these elemental services, the middleware 
provides a programming framework and associated libraries 
to facilitate development of run-time libraries that imple- 
ment protocols for iniddlcware-compliaDt service access and 
control 130 and brokering services 132. The program enti- 
ties mat are developed within this framework are objects (in 
) the object-oriented programming sense), called policy mod- 
ules or policies, that implement service and access control 
130 and brokering services 132. and constitute the client/ 
server software that provides services and service access. In 
other words, service managers 210-211 and service agents 
i 230-233 are policies that perform the service-specific nego- 
tiation and control functions that are required for service 
delivery. 

To control independently a dynamic mixture of services, 
the concept of context provides a place to instantiate a locus 

i of control for the composition of these services and facili- 
tates the multi-way negotiation needed to deliver the ser- 
vices to a variety of endpoints. This requires that the detailed 
attributes of various media services (feature control 
mechanisms, encoding choices, transport requirements, 

; delay and synchronization characteristics, etc.) be under- 
stood and agreed-to by service providers (service managers 
110-112) and service users (parties 220-221). 

The middleware introduces the idea of "negotiation" 
among members, typically between parties and service 

i managers, to allow services to be provided in a manner mat 
ensures compatibility and consistency of service delivery to 
the parties. The middleware provides a framework for 
incorporating policy modules into a system that are available 
for use by applications for performing service-specific nego- 

i tiation in reaction to changes to the context Policy modules 
can also be used during service delivery to provide service- 
control functions, eg., to tell a video server which video 
stream to send. Policy modules are essentially service- 
specific run-time libraries that implement service-specific 

i negotiation and control protocols. Communications by 
applications 113 with policy modules of service access and 
control 130 are effected through a service control API 131. 

Context service 120 with appropriate policy modules 
enables deployment of new multimedia services without 
having to enhance underlying network equipment Naming 
service 122 and trading service 124 also facilitate service 
composition by enabling applications to locate the services 
that are needed to meet the needs of the members in a 
context Brokering services 132 can be created that perform 
the function of garnering up appropriate party attributes, 
formulating the required trader query, and inviting the 
returned service manager into the context These brokers 
generally are service-type specific (eg., audio, video, shared 
application), and are implemented as separate services that 
can be added to a context Broker agents work with the 
brokering server to locate the needed service manager and 
add it to the context In some cases, a broker may be 
implemented as a policy module of context server 201 
which, by virtue of its ability to eavesdrop on all context 
transactions, can perform a service-location function. Nam- 
ing service 122 complements the brokering service by 
providing a facility for converting a middleware entity name 
to the transport network attributes required to connect to that 
entity. 

Naming service 122 serves both applications 113 and 
virtual transport service 126. Applications typically use 
naming service 122 to map a qualified CWID (eg., an 



09/30/2003, EAST version: 1.04.0000 



5,717,747 

9 10 

R164-coafanMnt address, such as a phone number) into a In order to make context service 120 aware of their 

virtual transport address (VTA, e.g., also an E.164- existence, the user policies of feature managers 300. 350 

conformant address). The VTA appended with a logical-port must register with context service 120. The registration 

identifier is Tianded" to virtual transport service 126 which procedure is shown in FIGS. 4 and 5. Upon its own creation 

uses naming service 122, once again, to map the qualified 3 by an admimstrator of MMCX server 100, at step 401 of 

VTA to transport-specific attributes. For example, say that a FIG. 4, or upon initialization of MMCX server Iff 

user has a CWID of 303.538.4071, then naming service 122 (whichever is earlier), at step 400, a feature manager 300. 

would be used by a context server 201 to map 350 registers separately each of its w prim 30MK 

303 538 4071.context_port to the VTA of that user's mem- 351-352 with context service 120 of MMCX server Iff, at 

ber context agent, which might be 303.538.4000. When the 10 step 402. As part of each registration with context service 

context server 2f 1 wishes to establish a connection to the 12f . a feature manager 300. 350 specifiesthe raKnty that 

context agent* s port for accepting context messages, it asks has been administered for each user policy. The priorities for 

virtual transport service 126 to establish a connection to all user policies of a feature manager may be all the same. 

303^38.4000.context_port Virtual transport service 126 or they may be different When the priority of one or more 

would, in turn, use naming service 122 to map 15 of its user policies is adrninistratively changed, the feature 

303 538.4000.context_port to the transport specific address manager re-registers with context service 12f with the new 

(es) of the appropriate virtual port on context agent 202. priorities. A feature manager 300. 350 also registers once 

This description of the middleware applies fundamentally with trading service 124 of MMCX server 100, at step 404, 

to both MMCX server 100 and endpoints 101-102, although before concluding registration, at step 406. 

APIsl21. 123, and 125 are theonry portions of services 120, 20 Subsequently, at any time whenever a new user is admin- 

122. and 124 that are used on endpoints 101-102. A dis- istcred for features or an existing user is administered for a 

tributed client/server architecture is utilized whereby client new feature, at step 410 of FIG. 5, each feature manager 300, 

software (service agents 230-233) in an endpoint 101-102 350 of the user's new features registers the user's new user 

works cooperatively with server software (service managers policies 301-302. 351-352 with context service 120 of 

210-211) in server 100 to provide the brokering services as 25 MMCX server, at step 41Z As part of the user policies 

well as uie media-control services which provide the value- registration with context service 120, each feature manager 

added communications services to users. 300, 350 specifics the priority that has been adnmustered for 

According to the invention, the above-described infra- the new user policy. Registration of the new user policies 

structure and call model are used to provide support for then concludes, at step 414. 

riue-and-play call features in the manner illustrated in FIG. 30 FIG. 6 shows the feature-adniinistration procedure for 

£ 6 feature admin, agents 303^304, 353-354. When a party 220. 

Feature software is implemented using the client/server 221 logs into an endpoint 101, 102, at step 500, each 
architecture. As shown in FIG. 3, each feature comprises a feature's feature admin, agent of the logged-into endpoint 
feature manager (a server module) 300, 350 on MMCX uses trading service 124 to find the identit y of the c oge- 
server 100 and a plurality of feature administration (admin.) 35 spending feature manager 300, 350 for the corresponding 
agents (client modules) 303-404, 353*454. one on each feature, at step 502, The feature admin, agent then uses the 
endpoint 101-102. Each feature manager 300, 350 is imple- identity to establish a communications connection with the 
mented as one or more user policies 301-302, 351-35Z one corresponding feature manager via administration API 300. 
for each user 220-221 mat is entitled to use the feature. Each at step 504, and determines from the feature manager 
user policy 301-302, 351-452 is one user's customized 40 whether there is a corresponding user policy for the logged- 
instancTof the feature manager 300, 350, respectively. in party 220, 221, at step 506. If there is not a user's policy 
Feature managers 300. 350 and their user policies that are for the togged-in party, the logged-in party is not authorized 
involved in a call are not members of that call's context 200, to use the corresponding feature, and so the feature admin, 
but each coinmunicates with context 200 through the party agent ends feature administration, at step 510. ff a care- 
context agent 203, 204 of its corresponding party 201, 202. 45 sponding user policy is found and its identifier is returned by 
User policies of the same and of different feature managers feature manager 300, 350 to the feature admin, agent, the 
300 350 keep track of each other through the event- logged-in party is authorized to use the corresponding 
notification mechanisms provided by context service 120, feature, and so the feature adinin. agent and the party's user 
but they generally do not communicate with each other policy then adnrinister the feature far the party by exchang- 
directly through an out-of-oontext exchange of messages. 50 ing that party* s *1erminal translations" dau (as that term is 

Unlike the feature managers, feature admin, agents commonly used in the telephony art), at step 508, before 

303*404, 353-354 are not »mpi*m»ntM u policies, feature ending administration, at step 510. The terminal translations 

admin, agents do not execute features, but rather only turn data that is provided by the party's user policy wfll have 

features on and off at endpoints 101-102 and communicate been pre-administered by an administrator of server 100. 

administrative information between parties 220*221 and 55 while the terminal translations data that is provided by the 

feature managers 300, 350. Feature admin, agents and their feature admin, agent is obtained by feature admin, agent 

corresponding feature managers communicate with each through interaction with the logged-in party through the 

other outside of context 200 through an adininistration API feature's corresponding one of the interfaces 114 on the 

360 that is implemented at the applications layer 113. endpoint 

Administration API 360 uses trading API 125 and ROM 60 Consider, for example, the adininistration for the call- 
service 127 to locate, and to communicate with, feature forwarding feature. The caU-f (awarding user interface on the 
managers 300, 350. Graphical user interfaces 114 and fea- endpoint invokes the feature administration AH 360, pass- 
ture admin, agents for any Dumber of features can be added ing it the caU-fcwarding feature identifier, the identifier of 
to (or deleted from) any endpoint 101-102 at any time, and the user who is administering call-forwarding, and a coUec- 
administration API 360 enables the interfaces and agents to 65 tion of call-forwarding administration data, including the 
locate, and to communicate with, the corresponding feature identifier of the forwarded-to party and whether cali- 
managers forwarding should become enabled or disabled. The feature 
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administration API 36# queries trading service 124 for the 
identifier of the feature server that matches the call- 
forwarding feature identifier, Le., the call-forwarding feature 
server. If trading service 124 successfully returns this 
identifier, the administration API 360 sends the call- 
forwarding feature server the user's identifier and the call- 
forwarding administration data. The call-forwarding feature 
server receives the data and stores it in its feature translation 
database. Henceforth, during call processing, the adminis- 
tration data can be retrieved from the feature translation 
database and used to effect the call-forwarding feature. 

For purposes of event-negotiation, event context 2## 
provides for three types of mter-member communications: 
proposals from initiators of events to context event requests 
for approval from context to interested policies (those 
affected by the event), and event notifications from context 
to all context members. Any proposed event that causes a 
change in context or a change of state of a context member 
must be approved by the policies of the acting context 
member and the policies of the members being acted on. For 
example, a request to create a context is an event that must 
be approved by all policies of the requestor; a request to add 
or delete a member to or from a context or to change a 
member's state is an event that must be approved by all 
policies of the requestor and the subject of the request; and 
a request to destroy a context is an event that must be 
approved by all policies of the requestor. 

FIG. 7 shows the event-negotiation procedure. When an 
event proposal is received by context 20# from a policy, at 
step ftO, context 204 determines from the event which 
context members need to approve the event, at step 6*2, and 
then sends event requests for approval to the policies of each 
member which needs to approve the event — first to the 
requestor's policies serially and sequentially in the order of 
the policies* priorities, and then to the policies of the subject 
or subjects of the request serially and sequentially in the 
order of the policies' priorities. Context 2*0 first sends an 
event-approval request to the highest-priority policy of the 
event-originator, at step 604. Upon receipt of an event 
request for approval, at step 630, each policy that is asked 
for approval of the event executes whatever algorithm it has 
been programmed with to determine its approval or 
rejection, at step 632, and sends its reply to context 200, at 
step 634. before concluding, at step 636. Context receives 
the policy's reply, at step 606, and checks whether it is an 
approval or a disapproval* at step 608. If any policy of any 
member who needs to approve the event replies with a 
rejection of the event, as determined at step 608, context 200 
notifies the policy that made the event proposal, at step 621, 
then ends, at step 622, and the event is not effected. If the 
received reply is an approval, context checks whether it has 
sent an event-approval request to each policy of the event 
originator, at step 610. If not context 200 returns to step 604 
to send the event-approval request to the next-highest pri- 
ority policy of the event originator. If all policies of the event 
originator have been sent event-approval requests, context 
200 proceeds to steps 612-418 to repeat the procedure of 
steps 604-418 for each policy of the event subjects. If all 
policies of all context members who need to approve the 
event reply with an acceptance of the event as determined 
at step 618. context 200 broadcasts notification of the event 
to all policies of all members of the context, at step 620, so 
that the policies can implement, or take note of, the event 
and ends, at step 622. The event notifications at step 620 are 
not prioritized. 

The policy priorities do not affect information messages, 
which are data messages or requests for information sent 
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between clients and servers through APIs such as adminis- 
tration API 360, for example. Their handling by APIs is 
shown in FIG. 8. Upon receiving an information message, at 
step 700. an API determines the message's destination, at 
s step 702, and forwards the message to that destination, at 
step 704, before ending, at step 706. 

To provide the above-described communications 
capabilities, the various APIs include the following mes- 
sages. 

o To allow an administrator of MMCX system 100 and 
parties 220-221 at endpoints 101-102 to administer the 
features, administration API 360 provides a message that 
comprises one function (command) and three arguments. 
The function is "admiiustration request**. The arguments are 

5 the identifier of the feature that is to be administered, the 
identifier of the party for which the adimnistration is being 
done, and the administration data for use by the message 
recipient 

lb enable feature managers and service managers to 

o register with context service 120. context API 121 provides 
a message that comprises one function and four arguments. 
The function is "policy registration request**. The arguments 
are the identifier of the feature or service, the user policy that 
is registering (the registrant), the name of the party repre- 

5 sented by the registrant, and the registrant's priority. 

To enable feature managers and service managers to 
register with trading service 124. trading API 125 provides 
a message that comprises one function and two arguments. 
The function is M manager registration request**. The argu- 

o meats are the identifier of the feature or service that is 
registering, and the CWID of the registrant 

To enable feature admin, agents and server agents to find 
suitable user policies and service managers via trading 
service 124. trading API 125 provides two messages. One 

5 message has a function of "server request** from the agent to 
trading service 124. and arguments of feature or service ID 
and feature or service parameters being requested by the 
agent The other message has a function of "server response** 
from trading service 124 to the agent, and an argument of 

o CWID of the feature's user policy or the service manager 
selected by trading service 124. 

Tb enable policies to initiate events, context API 121 
provides a message that comprises any one of six functions 
and four arguments. The functions are "create context**, 

5 "destroy context**, "add member**, "drop rocmbcr**, "change 
state", and "send message**. The arguments are the CWID of 
the initiator, the new state in the case of the "change state** 
function, the CWID of the event subject for the functions 
other than "create context" and "destroy context", and the 

D reason for the event 

To enable event requests for approval to be made, context 
API 121 provides a message that comprises one function and 
four arguments. The function is "request for approval". Hie 
arguments arc the function and arguments of the event- 

5 initiating message. 

lb enable event approvals and denials, and notification of 
denials to event originators, context API 121 provides a 
message that has one function and one argument The 
function is "approval reply". The argument is either 

3 approval or a failure code. 

To enable event notifications, context API 121 provides a 
message that comprises one function and four arguments. 
The function is "event notification". The arguments are the 
function and arguments of the event-Initiating message. 

5 lb enable in-context communication among context 
members, context API 121 provides a message that has one 
function and four arguments. The function is "send mes- 
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sage**. The arguments are the CWID of the destination party, 
the ID of the feature or service being communicated with, 
the ID of the user policy being communicated with, and the 
message data. If the policy ID is omitted, the message is sent 
to all user policies of the identified feature or service. 5 

To allow inf ormatioD-pas sing between user policies and 
feature admin, agents, administration API 34# provides a 
message that comprises one function and one argument The 
function is "administer'*. The argument is an arbitrary data 
field. 10 

Given this infrastructure, almost anyone can create a 
feature (that is. feature software) for use therein. Substan- 
tially the only requirements placed on the feature software 
are that (a) it have a client/server construction, that is, be 
constructed as a feature-manager server module plus a ]S 
feature admin, agent client module and (b) be compliant 
with messages of the interfaces (context API 121, adminis- 
tration API 360, and trading API 125 in this example) that 
were enumerated above, and with their functions. Compli- 
ance with requirements (a) and (b) above ensures that the ^ 
feature can both operate in the system of PIG. 1 and 
inter-operate with other features and services of the system 
of FIG. 1. In other respects, the internal structure and 
functionality of the feature are irrelevant to the system of 
FIG. 1 and its various components, bom hardware and ^ 
software. 

Of course, various changes and modifications to the 
illustrative embodiment described above will be apparent to 
those skilled in the art For example the context service need 
not be provided by a single server, but may be distributed ^ 
across a network of servers. Also, the industry-standard 
Object Management Group's (OMG's) object request bro- 
ker (ORB) could be used instead of the remote object 
management (ROM) services and the virtual transport (VT) 
services. Rirmermore, the middleware and its functions 35 
could be distributed over a plurality of servers. Also, addi- 
tional functions and messages may be added to the APIs. Or 
in addition to, or instead of, the context API protocol, the 
system can support other multimedia communication pro- 
tocols (eg., enhanced H.323, H320, T.120, conventional ^ 
audio telephony protocols). Such changes and modifications 
can be made without departing from the spirit and the scope 
of the invention and without diminishing Its attendant 
advantages. It is therefore intended that such changes and 
modifications be covered by the following claims. 45 

The invention claimed is: 

1. A call-control apparatus wherein each call feature is 
implemented as a server program and a cooperating client 
program, comprising: 

means for executing the client and the server programs; ^ 

means for registering for a user an instance of a server 
program that implements any call feature, in a same 
manner as any other instances of any server programs 
that implement any call features, substantially at any 
time during operation of the call-control apparatus to 53 
provide the call feature for the user; 

an administration interface for communicating 
information, between the server program and a coop- 
erating said client program used by the user. In a same 
manner as between any other client programs and any 60 
server programs that implement any call features, to 
customize the instance of the server program for the 
user; and 

means for involving the instance of the server program in 
a call to which the user is a party, in a same manner as 65 
any other instance of any server programs that imple- 
ment any call features, to provide the feature to the call. 
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2. The apparatus of claim 1 wherein: 

each instance of each server program has a priority 
associated therewith; and 

the means for involving comprise 

means responsive to occurrence of an event in the call* for 
giving instances of server programs that are involved in 
the call each a chance to respond to the event in an 
order of their associated priorities, to control interac- 
tion between the features implemented by the instances 
of the server programs that are involved in the call. 

3. The apparatus of claim 1 wherein 
the means for involving comprise: 

a second interface for comrnunicating events between a 
plurality of server programs that are involved in the 
call, in a same manner as between server programs that 
are involved in any other calls; 

means cooperative with the second interface, responsive 
to receipt through the second interface of a proposal of 
an event from a first server program that is involved in 
the call, for sending a request for approval of the event 
through the second interface to the first server program 
and to a second server program that is also involved in 
the call; 

means cooperative with the second interface and respon- 
sive to receipt through the second interface of approval 
of the event from both the first and the second server 
program, for sending the approval of the event through 
the second interface both to the first server program and 
to the second server piogiani to cause the event to be 
effected, and responsive to receipt through the second 
interface of rejection of the event from either the first 
or the second server program, for forbearing from 
sending the approval of the event both tome first server 
program and to the second server program to prevent 
the event from being effected. 

4. The apparatus of claim 3 wherein: 

each server program has a priority associated therewith, 
and 

the means for sending a request for approval are respon- 
sive to the receipt of the event, for sending the request 
for approval to the first and the second server programs 
serially in an order of the priorities of the first and the 
second server programs, to control interaction between 
the features implemented by the first and the second 
server programs. 

5. The apparatus of claim 4 further comprising: 
means for adimmstratively changing the priorities that are 

associated with server programs, to change the inter- 
action between the features implemented by the server 
programs. 

6. The apparatus of claim 1 wherein: 

the administration interface communicates information 
between the server program and the cooperating client 
program used by the user to cu stomize a registered said 
instance of the server program for the user; and 

the involving means involve a customized registered said 
instance of the server program in the call to which the 
user is a party. 

7. The apparatus of claim 1 wherein: 

each feature's server program comprises a plurality of 
instances of the server program, one for each user who 
is entitled to the feature. 

8. The apparatus of claim 1 wherein: 
the executing means comprise 

means for executing the server programs, and 



09/30/2003, EAST version: 1.04.0000 



5,717, 

15 

at least one means for executing the client programs; 
the server programs, the means for executing the server 

programs, the registering means, and the involving 

means are included in a call controller; 
an instance of the client program of each of at least some 3 

of the features and one of said means for executing the 

client programs are included in each of at least one call 

endpoint; and 

the administration interface interfaces the at least one call 1Q 
endpoint with the call controller to communicate infor- 
mation between server programs on the call controller 
and the instances of the client programs on the at least 
one endpoint. 

9. A method of controlling calls in an apparatus wherein 15 
each call feature is implemented as a server program and a 
cooperating client program and which executes the client 
and the server programs, comprising the steps of: 
in response to a user becoming entitled to a call feature, 
registering for the user an instance of the server pro- 20 
gram that implements the call feature, in a same manner 
as any other instance of any server programs that 
implement any call features, substantially at any time 
during operation of the apparatus, to provide the call 
feature for the user. 
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in response to the user using the client program, commu- 
nicating information between the server program and 
the client program through an administration interface. 

in a mme manna- as information is Communicated 

through the administration interface between any other 
client programs and any server programs that imple- 
ment any call feature, to customize the instance of the 
server program for the user; and 

in response to the user becoming a party to a call, 
involving the instance of the server program in the call, 
in a same manner as any other instance of any server 
programs that implement any call features, to provide 
the feature to the call. 

It. Hie method of claim 9 wherein: 

each instance of each server program has a priority 
associated therewith; and 

the step of involving comprises the step of 

in response to occurrence of an event in the call* giving 
instances of server programs that are involved in the 
call each a chance to respond to the event in an order 
of their associated priorities, to control interaction 
between the features implemented by the instances of 
the server programs that are involved in the call. 

♦ * * * * 
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ABSTRACT 



A system and method for creating and modifying intelli- 
gent telephone network call processing logic trees 
which can be customized for individual customers and 
created in a user-friendly visual environment (10, 15, 
FIG. 3-5). Service primitives are defined as logical 
graph nodes (20, FIG. 2, FIG. 3) which can be visually 
assembled into logic trees (FIG. 5) which represent the 
service logic flow and which provide default values for 
all service options. Higher level nodes, assembled from 
a plurality of service primitives, can likewise be defined 
and stored (12, 13, 19) for later use as entities in defining 
yet further call processing logic trees. These call pro- 
cessing logic trees are interpreted to allow the service 
control point computers (17) to implement the services 
in the switched telephone network (18) by sequentially 
executing the specified call processing primitives. A 
library (12, 13, 19) of defined nodes and defined node 
assemblies which represent service features can thus be 
made available to permit graphical manipulation into 
complete logic trees representing new services. These 
logic trees are then interpreted by generic programs in 
the service control point to actually provide the de- 
scribed services. 

17 Claims, 4 Drawing Sheets 
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FIG. 5 
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VISUAL PROGRAMMING OF TELEPHONE 
NETWORK CALL PROCESSING LOGIC 

TECHNICAL FIELD 5 

This invention relates to the creation and the provi- 
sioning of special customized telephone network ser- 
vices for telephone subscribers and, more particularly, 
to a portable, visually programmed call processing logic 
interface for creating and provisioning such customized 10 
services. 

BACKGROUND OF THE INVENTION 

New telephone services are continually being devel- 
oped by telephone service providers in order to meet 15 
the needs of their customers. As such services become 
available, the telephone companies, subscribers and the 
users seek yet further improvements in these services. 
Special services such as 800 service, 900 service, and 
Private Virtual Networks (PVN) are only a few of the 20 
possible services being offered. Other services might 
well be conceived and might well find extensive use. 
Unfortunately, however, new telephone services have 
heretofore required long and expensive design, testing 
and deployment activities.. Such special telecommunica- 25 
tions services are typically provided in the public tele- 
phone network by computer program call processing 
sequences residing in digital switches. A typical ap- 
proach to providing such special services is the intro- 
duction into the telephone network of a service imple- 30 
menting network element which interacts with the tele- 
phone network so as to implement the telephone ser- 
vices. Such service implementing network elements are 
variously called Service Adjuncts (SAs), Service 
Switching Points (SSPs) and Service Control Points 35 
(SCPs). One such Service Adjunct is disclosed in S. M. 
Lin and J. F. Rizzo U.S. Pat, No. 4,878,240, granted 
Oct 31, 1989. A typical Service Switching Point is 
disclosed in J, J. Bernardis U.S. Pat. No. 4,782,517, 
granted Nov. 1, 1988. Finally, a typical Service Control 40 
Point is disclosed in J. O. Boese et al. application Ser. 
No. 453,042, filed Dec. 12, 1989. Each such service 
implementing network element is equipped with a set of 
software-implemented service primitives which can be 
combined in various ways to implement a number of 45 
telephone services. A set of such primitives for a Ser- 
vice Adjunct is disclosed in the above-mentioned Lin et 
al. patent Another set of primitives for a Service 
Switching Point is disclosed in the above-mentioned 
Bernardis et al. patent. Yet another set of such primi- 50 
tives for a Service Control Point is disclosed in "Busi- 
ness Services Database (BSDB): A Service Control 
Point (SCP) Application Designed to Support Private 
Virtual Network (PVN) Service, "Technical Advisory 
TA-TSY-000460, Issue 2, February 1988, published by 55 
Bell Communications Research, Inc., Red Bank, NJ. 
All of these sets of service-implementing primitives are, 
as a group, generally equivalent, although each is imple- 
mented in a slightly different way. 

A telecommunications network including such pro- 60 
grammable special service implementing components is 
called an "intelligent network.'* Such networks make it 
possible to offer useful and profitable new services such 
as 800 service, Alternate Billing service and Private 
Virtual Network service. Intelligent Network Call Pro- 65 
cessing Logic (INCPL) is the name given to the soft- 
ware that "stitches together" the appropriate service 
primitives to enable the Intelligent Network mechanism 



,452 

2 

to implement and customize such services without the 
need for new switch software or hardware. Currently, 
this INCPL is custom-developed for each new service 
by a service designer, usually associated with the ser- 
vice provider, installed in the intelligent network ser- 
vice implementing component and supported by a ser- 
vice management system for that service. Thus, instead 
of the software to support a new service coming from a 
switch vendor, it can now come from a service vendor, 
making it possible to reduce the interval between ser- 
vice concept and service offering. Unfortunately, a 
great deal of time is still required to design custom and 
implement each new service. Moreover, since such 
service designs are not highly portable, further delays 
arise due to the need to provide widely distributed 
software elements to support the new service in a wide 
variety of different environments. 

SUMMARY OF THE INVENTION 

In accordance with the illustrative embodiment of the 
present invention, these and other problems are over- 
come by providing a user-friendly environment in 
which intelligent network service primitives can be 
assembled into telephone services utilizing the graphic 
capabilities of a computer workstation. If a complete 
telephone service is analyzed as a graph consisting of 
nodes and edges, the nodes represent the intelligent 
network service primitives executable by the service 
implementing components and the edges represent the 
order of execution of these primitives. Both action 
nodes and decision nodes can be defined in terms of the 
available service primitives and stored for later use in 
designing a new telephone service. Moreover, with this 
representation, the new telephone service can be dis- 
played as a "tree" of such node. Such a tree display can 
be manipulated graphically to create and alter the logic 
of a service. An interpreter program, designed for a 
particular service implementing component, imple- 
ments such display representations with the available 
adjunct service primitives. In accordance with this in- 
vention, telephone services can be created, manipulated 
and altered by simple, user-friendly graphical manipula- 
tion. Not only can intelligent network service primi- 
tives be assembled graphically into new services, but 
service features can be defined as assemblies of such 
intelligent network service primitives and, once de- 
signed, stored in a library as a single node to be invoked 
and reused as a single entity in designing a plurality of 
future services. 

More particularly, graphical images or icons on a 
display screen are used to represent a reusable library of 
user-defined telephone service primitives. These images 
or icons can be manipulated graphically so as to assem- 
ble the images into logical trees representing new ser- 
vices or new service features. Once fully assembled, the 
electronic representation of the graphical service tree 
or service feature tree can be interpreted so as to actu- 
ally implement the service or service feature. In this 
way, new telephone services can be designed and imple- 
mented much more quickly than in the prior art and 
thus save much of the expense previously associated 
with telephone service design and deployment. In addi- 
tion, the extremely high level representation of tele- 
phone services implicit in the graphical service trees is 
an extremely portable mechanism for quickly and easily 
deploying such services without extensive reworking of 
service implementing code. Indeed, the simplicity. 
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speed and flexiblity of telephone service design and service nodes which are used to design and implement a 

implementation provided with the present invention particular advanced telephone service in the system of 

can be exploited to allow each individual telephone user FIG. 1; and 

to custom design telephone services exactly matching FIG. 5 is a graphical representation of a display 

the needs of the customer. 5 screen used to customize a logical tree template of ser- 

The present invention makes possible dynamic graph- vice primitives by specifying all of the customer- 

ical creation, customization and provisioning of new dependent variables required to implement a particular 

call processing services. Using both simple nodes, here- new service for a particular customer in the system of 

into called primitive nodes and consisting of, primitives FIG. 1. 

and complex" nodes that are user-defined constructed 10 To facilitate reader understanding, identical refer- 

nodes and are called user defined service feature nodes, ence numerals are used to designate elements common 

new services can be defined rapidly and with great ease. to the figures. 
A new service is created visually as a logic tree with 

nodes defined to represent a high-level abstraction of DETAILED DESCRIPTION 
the primitive call processing actions or call processing 15 Referring more particularly to FIG. 1 of the draw- 
decision points or combinations of such primitive ac- ings, there is shown a general block diagram of an intel- 
tions and decision points. This tree, or the electronic ligent network telephone service design and deploy- 
representation of the tree, is called a Call Processing ment system comprising a workstation 10 for designing 
Record (CPR) since it defines exhaustively the process- new telephone services in accordance with the present 
ing necessary to provide an individual call with the 20 invention. As will be described hereinafter, workstation 
defined service. Service providers, as well as subscrib- 10 includes graphical facilities for defining customer 
ers themselves, can customize and provision the graphi- special service nodes in terms of service control point 
cally defined service to satisfy specific customer needs primitives, bounding new special services in terms of 
by dynamically modifying and parameterizing the rele- the thus defined nodes which can be used for that ser- 
vant graphical call processing record trees. The thus 25 vice, and assembling these telephone service nodes into 
provisioned call processing records representing the templates or assemblies of call processing logic units 
service can then be translated from the user-friendly capable of providing the new telephone special ser- 
visual format to a rigorous program-generating format vices. Service creation process 11 provides the software 
which can be generically interpreted by existing service for supporting these facilities and includes standard 
implementing components. The distribution and instal- 30 window processing capability as well as mouse or other 
lation of such call processing records to appropriate visual selection apparatus support, and is typically 
service implementing components in an intelligent net- stored in the program memory of workstation 10. Stor- 
work enables the thus-described service to become age device 12 stores a library of the electronic represen- 
instantly available to telephone subscribers. tations of all of the nodes previously specified, both 

There are three steps in this service specification 35 simple primitive nodes and more complex, user-defined 

process: 1) defining the nodes, 2) establishing which service feature nodes. Storage device 13 stores the defi- 

nodes can be used in a particular service, and, 3) creat- nitions of all of the services defined at workstation 10, 

ing call processing records defining a particular service where a service definition is simply the specification of 

using the nodes that have been defined, and to which which of the defined nodes (primitives) can be used to 

can be added the customer-specific parameters neces- 40 implement a particular service. Storage device 19 stores 

sary to completely specify the service. These three steps templates of multinode fully designed services as call 

can be iterated interactively to improve the quality of processing records. In the present application, a **tem- 

the resulting service, to remove "bugs," or to provide plate" is a fully designed service, but without all of the 

new features and capabilities. variable parameters which are dependent on the actual 

Other aspects of a service creation and provisioning 45 customer using the service. Although shown as separate 

system are disclosed and claimed in the copending ap- storage devices, stores 12, 13 and 19 can be contained in 

plications of D. L. Babson, J. A. Bajzath, Jr. and T. C. a single storage device. 

Ely, Ser. Nos. 629,371, 629,389, 629,390 and 629,447, all The present invention contemplates three steps in 

filed of even date herewith and assigned to applicants' creating new services, defining graphical nodes from 

assignee. 50 which services can be assembled (node definition), pre- 

BRIEF DESCRIPTION OF THE DRAWINGS 5 crib " lg ^f 1 . 110 ?* can be used in a particular service 

(service definition) and prescribing the logical interrela- 

A complete understanding of the present invention tionships of the various nodes necessary to produce the 

may be gained by considering the following detailed desired service (call processing record creation). As 

description in conjunction with the accompanying 55 new nodes are defined, they arc stored in node library 

drawings, in which: 12 for later retrieval and reuse. Once a new service is 

FIG. l/shows a block diagram of an intelligent tele- fully defined in terms of primitive or complex service 

phone network including a graphical telephone service nodes, a representation of that service definition is 

design and deployment system in accordance with the stored in a service definition storage facility 13. Once 

present invention; 60 the service nodes are assembled into a service logic tree 

FIG. 2 shows a flowchart of the service definition, or template, that template is stored as a call processing 

provisioning and implementation processes taking place record (CPR) in call processing record template library 

in the system of FIG. 1; 19. The templates in library 19 require only the specifi- 

FIG. 3 is a graphical representation of a display cation of certain customer-dependent variables required 

screen used to define new telephone service primitives 65 to fully implement the service for a particular customer, 

in the system of FIG. 1; A services management system 14 provides adminis- 

FIG. 4 is a graphical representation of a display trative control over a plurality of service control points 

screen used to define the allowable subset of telephone such as service control point 17 which actually imple- 
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ment the new services by exchanging network control 
messages with the switched telephone network 18. The 
details of the service control point 17, along with its 
interaction with the switched telephone network 18, are 
detailed in the aforementioned copending application of 
J. O. Boese et al. Since the structure and operation of 
the service control point 17 and the switched telephone 
system 18 comprise well-known telephone facilities, 
they will not be further described here. Sufficient to 



service management system 14 of FIG. 1 and imple- 
mented by the service control point 17 of FIG. 1 with- 
out the necessity of writing new service implementing 
code. As illustrated in FIG. 3, the user is presented with 
an on-screen form which requires that the user specify 
the values for each of these properties, The cursor ini- 
tially is located at the first data field (NODE NAME:) 
and advances to successive data fields as the < enter > 
or <return> key is depressed. Once these properties 



, " — : — w«««v.™ vi viciura^ *cy is depressed, unce tnese properties 

note that these elements are able to implement tele- 10 have been specified, the user can store the completed 

nllOne network Q^rvin* nrimifiu«e %i*h;s.tt J_n_:^ . . . . r 



phone network service primitives which can be utilized 
to realize telephone services and which are similar or 
identical to those disclosed in the aforementioned J. J. 
Bernardis and S. M. Lin patents and BSDB publication. 

Associated with the services management system 14 15 
is a customer data base 16 which contains detailed infor- 
mation concerning the customers utilizing telephone 
network 18. Also associated with services management 
system 14 is a further computer workstation 15 which 
can be used to add customer preferences and other 20 
customer specific data to the call processing record 
templates defined in store 19. This addition of the cus- 
tomer specific data to a call processing record template 
is called "service provisioning" and permits the service 



node definition for the newly created node in a node 
library in store 12 (FIG. 1), using the command keys 
identified in the top portion of the screen display of 
FIG. 3. 

The properties captured by the node definition screen 
of FIG. 3 contain key information about the new node 
and, when necessary, can be translated and sent to the 
service control point 17 of FIG. 1 to drive a generic 
Call Processing Record (CPR) interpreter (such as that 
disclosed in the aforementioned Bernardis patent), so 
that it can support the use of this new node in any call 
processing records that are created and provisioned for 
services. Additional or supplemental properties, such as 
associated service control point call variables, node 



. «- ; © — v*w ^ t.w «wwuwu aciviwc cumroj point cau vanaoies, node 

templates passed to service control point 17 to be cus- 25 connection rules and node translation rules, can be 

tOmiZed for a naiticular customer nr ert nf mictjtm*** n AA^A i:u _ ^ . . „ 



tomized for a particular customer or set of customers 
using network 18. Workstation 15 can, of course, be 
combined with workstation 10 if the two workstations 
are at the same location. 

The workstations 10 and 15 can be any modern work- 
station supporting graphical manipulation capability. 
One such workstation is the SUN 3/160 terminal run- 
ning under the SUN operating system and using the 
SUNVIEW® graphics environment. This environ- 



added to the node library at a later time to completely 
characterize the meaning and intent of these operations 
at a particular services management system 14 and a 
particular service control point 17 (FIG. 1) in a generic 
30 manner. More particularly, a specific identification of 
the service implementing primitive in one or more ser- 
vice implementing network components which can be 
used to realize the node can be explicitly added to the 

~ -\ *v • * node definition. The presence of such an identification 

ment provides window support, mouse control, and 35 of the actual code sequence in the service control point 
graphic creation and manipulation capability adequate would substantially simplify the design of the interpre- 
to implement the present invention. Many other modern tor program which translates the call processing record 
workstations, however, would likewise support imple- into actual service implementation. In this sense, the 
mentations of the present invention. nodes become elements of an extendible, high level 

The present invention will be better understood by 40 programming language for specifying telephone ser- 
considenng the flowchart of FIG. 2. In FIG. 2 there is vices. ° * * ^ * z v 
shown a flowchart of the process for designing and In response to the NODE NAME prompt, the user 
deploying new services for telephone subscribers in supplies any unique name chosen for the new node. This 
accordance with the present invention. Three major name will hereafter be used to identify the node. This 
steps are involved, node definition, service definition 45 new node name can be thought of as a higher-level 
and call processing ; record creation. These steps will be abstraction representing a specific operation using pre- 
taken up individually below. defined call processing variables. Nodes can be either 

The intended user of the process of FIG. 2 is the decision nodes or action nodes. The following node 
service creator, typically the telephone service pro- types, supplied in response to the NODE TYPE 
vider. As suggested in box 20 of FIG. 2, this person 50 prompt, are possible: 
must create the nodes to be used in new services. The _ 

new nodes are created dynamically by specifying the TABLE 1 

following properties of the new node. 

1. Node Name 

2. Node Type 

3. Data Type 

4. Node Rules 

5. "Other" Allowed 

6. Node Error Message 

7. Notes 

As is shown in detail in FIG. 3, a node definition 
screen can be used to capture the node properties as 
data items. The "Load," "Validate," "Store," "Delete," 
"Browse," "Help," and "Quit" command buttons are 
utilized to access and process nodes as entities. The data 65 
acquisition fields are used to define new nodes by speci- 
fying the node name and the node properties. Using 
these properties, a node can be administered by the 



NODE TYPES 



55 



60 



ACTION 


DECISION 


NODES 


NODES 


Asttgnmenl Action 


Branch Decision 


Boolean Operation Action 


Integer Decision 


Collect Action 


Percent Decision 


Connect Action 


String Decision 


Concatenate Action 




CPR Access Action 




Diagnostic Action 




Return Action 




Table Access Action 




Temporary Hand Over Action 




Terminate Action 





The node type selected provides information that can 
be used during call processing record validation and 
call processing record code generation. These node 
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types correspond to all of the basic types of actions and The NOTES prompt permits a convenience field for 
decisions that might be utilized in providing telephone the user. It can be used to note limitations on the node 
special services. They are already programmed or pro- behavior, a general functional description of the node or 
grammable into prior art service implementing network any other information the user wishes to associate with 
components such as service control point 17. Should a 5 the node definition. 

new type of node be required, however, it is necessary Also shown at the top of screen 30 of HO. 3 are a 
to specify the new type, and to provide generic imple- series of command light buttons labeled "Load," "Vali- 
mentation of the activity of the new node type in the date," "Store," "Delete," "Browse," "Help," and 
service control point 17. "Quit." These command buttons are operated, for ex- 

The node types have particular meaning to service 10 ample, by a mouse-driven cursor, to accomplish the 
control point 17, which must execute the call processing associated screen display control functions. For exam- 
record in real time. Specifically, the node type informs pie, "Load" will load any particular previously existing 
service control point 17 what functions or call primi- node definition (e.g., for editing) simply by giving the 
tives are to be invoked. These node types thus represent node name and evoking the "Load" command. Simi- 
the "programmed capabilities" of service control point 13 larly, "Validate" performs the validation on the data 
17, which, when combined with the node name, repre- entries made in response to the prompts. "Store" stores 
senting a particular pre-defined call variable in the ser- the newly defined node in the node library 12 of FIG. 1. 
vice control point call processing execution environ- The "Delete" command deletes the identified node 
ment, enable service control point 17 to actually per- definition from library 12. "Browse" allows the user to 
form the requested operations using the correct data. 20 browse through all of the previously defined nodes, 

The DATA TYPE field specifies the format of the "Help" provides screens of useful ancillary information 
data that will be acceptable as input values for this node likely to be of assistance to the user during the node 
when this node is used in a call processing record. The definition activity, and "Quit" allows the user to termi- 
data formats allowed are decimal numbers, alphanu- nate the node definition activity. The implementation of 
meric text, telephone numbers, trunk identifiers, van- these so-called "command buttons" are well-known in 
able data, and billing information. The data type is used the art and will not be further described here, 
during call processing record validation at the time the Returning to FIG. 2, the second box 21 represents the 
call processing record is "provisioned" by the specifica- activity of defining a new service in terms of previously 
tion of customer-dependent data values. 3Q defined nodes; In this context, a "record" is a service 

To administer a call processing record, services mari- definition and box 21 includes "Load," "Validate" and 
agement system 14 of FIG. 1 must be able to determine "Store" commands for these service definition records, 
whether valid values have been entered for the nodes in In addition, box 21 includes "Canvas" commands, 
the call processing record tree. Therefore the user must These commands permit the visual and graphical ma- 
specify the rules to be used when validating the input 35 nipulation of previously defined nodes into service defi- 
values for this node when this node is used in a call nitions. As can be better seen in FIG. 4, the left half of 
processing record. In accordance with the present in- the screen 40 is the drawing area where visual represen- 
vention, a regular expression can be used to represent tations of previously defined nodes can be assembled 
the validation rules. Moreover, such validation rules into service definitions. The "Canvas" commands in- 
can be entered dynamically in the node definition as 40 elude "Clear" (to clear the canvas area), "Draw" (to 
opposed to hard coding them in a program. For exam- prepare for manipulating items on the canvas), "Help" 
pie, to specify the validations for a queuing node, the (to obtain screens of useful information to assist in the 
user can specify the regular expression " (lifo | fifo)$". use of the system), and "Quit 1 * (to terminate the service 
This expression states that the node can accept either definition session). In addition, individual items in the 
"last in, first out" or "first in, first out" queue behavior 45 canvas area can be manipulated with the commands 
as input values. "Select" (to select a particular node), "Add" (to add a 

In response to the OTHER ALLOWED, prompt, selected node to the service definition), "View" (to 
the user must specify whether the node can accept the view the node definition of the selected node), and 
word "other" as an input value. For example, if a day of "Delete" (to delete a node from the service definition), 
the week node were defined and available for a particu- so The intended user of the service definition process is 
lar service, a call processing record would be con- the service creator. This creator utilizes the service 
structed with the day of the week node in the tree. If the definition process to define the subset of nodes in the 
input values for the day of the week node were specified node library that are to be used in a specific service. The 
as "Monday and Tuesday," then a second branch would user is presented with the form shown in FIG. 4 which 
need to be created to cover what should be done on 55 enables the user to specify the nodes from the node 
Saturday, Sunday, Wednesday, Thursday and Friday. library that are allowed for use by a specific service 
Rather than spell out the remaining days, the string with a certain qualifier. A qualifier could, for example, 
"other" could be used. For some nodes "other" is not a be a specific area of service in the service provider's 
sensible value. Therefore, during node definition, the territory. With the functions described above, the use of 
user must indicate whether "other" is a valid input 60 any particular node in a service can be defined by a 
value or whether entering "other" should result in a service creator and administered by the service manage- 
validation error. ment system 14. Once the allowable node names for a 

In response to the NODE ERROR MESSAGE particular service have been specified, using the screen 
prompt, the user enters a string to be printed when an 40 of FIG. 4, the user can store the service definition for 
inappropriate input value is specified for a node during 65 the new service in service definition library 13 (FIG. 1). 
the provisioning of a call processing record. This allows These service definitions can thereafter be edited, aug- 
"on the fly" validation of data entries during all sue- mented or deleted from the service definition library 13 
ceeding uses of this node definition. whenever desired. 
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The service creation user can distribute the node 
library and the service definition library in store 13 to 
the generic service management system 14 for use in 
administering the new service. Services management 
system 14 .will permit the use of only the specified subset 5 
Of nodes in all call processing records that are created 
and provisioned for this particular service. Additional 
properties, such as service-specific node connection 
rules and node translation rules, can be added to the 
service definition tables at this time to completely and 10 
genetically characterize the meaning and intent of these 
operations for the service management system 14. 

Returning to FIG. 2, the box 22 represents the proce- 
dures for "provisioning" the service defined in box 21. 
In this regard, the term "provisioning" means creating 15 
the logic tree representing the new service and custom* 
izing the defined service in terms of node parameter 
values. The screen 50 of FIG. 5 illustrates a mechanism 
for carrying out this process. The service creator can 
use this process to define a default representation of the 20 
service offering as a template of nodes interconnected in 
a call processing record tree format The allowed nodes 
for a particular service are the ones specified through 
the service definition process. The service provisioning 
user can use this process to customize the default ser- 25 
vice template and to provision the service with node 
parameter values. The user is presented with the visual 
programming tool illustrated in FIG. 5 to enable a 
graphical, user-friendly specification and input of the . 
appropriate service customization and provisioning 30 
information, based on service, qualifier and customer 
key information. The qualifier could be, for example, a 
specific area of service in the service provider's terri- 
tory. The screen of FIG. 5 provides record manipula- 
tion functions (Load Record, Validate Record, Store 35 
Record, and Translate Record), node manipulation 
functions (Place, Connect, Move, Edit, Disconnect, and 
Remove), and draw commands (Select, Clear, Help, 
Quit, and Redraw). 

With the above described functions, the user can 40 
define a service template of nodes interconnected in a 
call processing record tree format as a default represen- 
tation of the service offering. Furthermore, the true 
power of the present invention becomes evident when it 
is realized that the service creator can define modular 45 
templates of common reusable node-based logic as ser- 
vice features, which can then be added to the node 
library as nodes for reuse by other features and services. 
In effect, the present invention provides a mechanism 
for using the set of "programmable capabilities" avail- 50 
able at the service control point 17 and define reusable, 
user-friendly and high-level modules that enable easier 
and Caster visual programming of the call processing 
logic. 

It should be noted that assemblies of low level nodes 55 
can be associated together into a higher level capability 
which, once given a name, can be retrieved, manipu- 
lated and used in creating new services just like a low 
level node. In this way, as time proceeds, the creation of 
new services becomes easier and easier since ever 60 
higher levels of service primitives become available for 
assembly into the new services. 

Once the default service template has been specified, 
the user can store the service template definition for the 
new service in service template definition store 19. The 65 
user can thereafter distribute these service template 
definition tables to the generic services management 
system 14 for use in administering the new service, 
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providing a default service logic flow for the purpose of 
provisioning. Furthermore, the availability of service 
node definitions in store 13 will ensure that provisioning 
will support the use of only the creator-specified subset 
of nodes in any call processing records that are custom- 
ized and provisioned for this particular service. 

The service provider or the subscriber can also use 
the process illustrated in FIG. 5 to customize the default 
service template and to provision the service by provid- 
ing node parameter values. At this stage, the node val- 
ues supplied are validated dynamically by invoking the 
node validation rules specified for each node name in 
the node library. Additional node and service definition 
properties, such as node connection rules and node 
translation rules, can be specified to drive the validation 
and translation operations at the services management 
system 14 in a generic manner. 

The attached Appendix provides psuedocode for 
implementing the flowchart of FIG. 2. With this 
pseudocode and the description herein provided, any 
person of ordinary skill in the programming art is able 
to fully implement the present invention. 

It should also be clear to those skilled in the art that 
further embodiments of the present invention may be 
made by those skilled in the art without departing from 
the teachings of the present invention. 



APPENDIX 

Pseudocode 

Node Definition Process Pseudocode 
invoke Onode— definitionO 
do until (invoke Cquit*)) 
tf (view (node-definition)) 
then input (node—name) 
invoke (Toad*) 

if (node— definition (node—name) in library 
then 

retrieve (node—definition (node— name)) 
display (node— definition (node— name)) 
else 

create (node_definition_ window (node— name)) 
display (node— definition— window (node— name)) 
endif 

end — invoke 
endif 

if (specify (node— properties)) 
then 

set—default (field— values (node-name)) 
enter (field— values (node_name)) 
else 

if (modify (node— properties)) 
then update (field- values (node— name)) 



k(i 



endif 
if(validai 
then 

invoke (Validate*) 
verify (nodi 



field— entries, field— entry- 



end— invoke 
endif 

if (store (node— definition)) 
then 
invoke fstore*) 
retrieve (node-definition (node— name)) 
overlay (node— definition, node— properties) 
store (overlay (node— name)) 
end— invoke 
endif 

if (delete (node— definition)) 
then 
invoke fdelete') 
retrieve (node— definition (node— name)) 
delete (node— definition (node name)) 
end— invoke 
endif 
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•continued 



APPENDIX 
Pseudocode 



APPENDIX 
Pseudocode 



if (browse (node-definition) 
then 

invoke ('browse') 

dispUy (node properties) 

retrieve (node— definitions) 
display (node— definitions) 

end—invoke 



ice, name, service 



Service Definition Process Pseudocode 
invoke f service . definition') 
do until (invoke Cqtrit*)) 
if view (service— defniition) 
then 

input (service— name, service— qualifier) 
invoke Ctaad'). 

retrieve (service— definition (servi* 

qualifier)) 

end— invoke 

if view (all— nodes) 
then 
mvoke Csetccf) 

generate (menu (all— nodes)) 
end—invoke 
endif 

if (select-node) 
then 
invoke Csekct*) 
select (desired —node, menu (all .nodes)) 
display (derimt n ode, currcnUjodr display) 
end— invoke 
endif 

if use (current—node) 
then 
invoke fadd*) 
position (current— node, canvas) 
add (current— node, service—definition) 
end— invoke 
endif 

if disallow (current— node) 
then 
invoke f delect') 
select (current-node) 
delete (selected-node) 
end— invoke 
endif 

if view (ciirrent_node— definition) 
then 
invoke (View*) 
select (current— node) 
display (node— definition, current— node) 
end— invoke 
endif 

if validate (servkx-definition) 
then 

invoke (Validate') 

verify (field-entries, service-definition) 
verify (field-entry— combinations, service— definitions) 
end— invoke 
endif 

if store (service^deftnition) 
then 
invoke f store') 
retrieve (service— definition (servicr name, service- 
qualifier)) 

overlay (service— definition (service— name, service— 

qualifier^ canvas nodes)) 
store (service— definition (service-name, service— qualifier)) 
end— invoke 
endif 

if dear (canvas— area) 
then 
invoke (*clear*) 

clear (ill— nodes, canvas— area) 
end— invoke 
endif 

if redraw (canvas— area) 
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then 
invoke Cdraw*) 
clear (all— nodes, canvas-^area) 
auto— invoke Ooad*) 
end— invoke 
endif 
end-do 
CPR Input Process Pseudocode 
invoke CCPR— input') 
do until invoke Cquit*) 
If view (existing— CPR_ tree) 
then 

input (servicr name, qualifier— name, customer— name) 
invoke (load*) 

retrieve (node— names (service— name, service., qualifier)) 
retrieve (node— definitions (node— names) 
retrieve (CPR— tree (service-name, service- 
qualifier, customer— name)) 
display CPR-_tree (service—name, serine qnahfer. 
customer name)) 
end— invoke 
endif 

if view (allowed nodes (service— name, service-qualifier)) 
then 
invoke Csekct*) 

generate (menu (allowed— node— names)) 
end— invoke 
endif 

If select (allowed— node) 
then 
invoke ('select') 
identify (nVsirrrl node) 
display (desired node, current node) 
end— invoke 
endif 

if add (current— code, CPR— canvas) 
then 
invoke Cplace') 
position (current— node, CPR— canvas) 
place (current— node, CPR— canvas) 
end—invoke 
endif 

if connect (node— namel, node name?. CPR— canvas) 
then 
invoke (connect) 
select (from— node) 
■elect (to— node) 

draw— line (from node, to— node 
end— invoke 
endif 

if move (node— name) 
then 
invoke (move) 
erase (node name, old— location 
redraw (connections, old— location, new— location) 
end— invoke 
endif 

then * 
invoke Cedlt*) 
select (node— name) 
display (edit— menu) 
input (node— value) 
invoke Center*) 
erase (old— value) 
display (new— value) 
end— invoke 
end— invoke 
endif 

if disconnect (node name) 
then 

invoke Cdisconnect*) 
select (node— name) 

erase— connection (node— name, node— parent) 
end— invoke 
endif 

if remove (node— name) 
then 

invoke Cremove') 
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APPENDIX 
Pseudocode 



select (node—name) 

remove (nodr name, children, connections) 
end—invoke 
endif 

if validate (CPR-node) 
then 

invoke ('validate') 
for (each node in CPR— tree) 
do 

validate (node— value, node— rule) 



display (error— messages) 
correct (node-. values, connections) 
end— invoke 
endif 

if store (CPR-tree) 
then 
invoke Cstore*) 
retrieve (CPR— tree (service— name, service— qualifier, 

customer— name)) 
overlay (CPR— tree (service— name, service qualifier, 

customer—name), CPR_tree (canvai_area)) 
store (CPR-tree, overlay) 
end— invoke 
endif 

if clear (canvas— area) 
then 
invoke (*dear*) 

erase (canvas— area) 
end— invoke 
endif 

if redraw (canvas— area) 
then 
invoke Credraw*) 
erase (canvas— area) 
auto— invoke (load*) 
end— invoke 
endif 
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What is claimed is: 

1. A method for visually programming telephone 
services for implementation in a telephone network 40 
having a service control point, said method comprising 
the steps of 

defining new nodes of network service primitives for 

storage in a storage means, 
recalling from said storage means previously defined 45 

nodes, 

assembling a set of said defined new nodes and re- 
called nodes to be used in one of said telephone 
services wherein said assembled set of nodes can be 
stored as a service definition in a service definition SO 
library, 

graphically interrelating said assembled nodes into a 
logical graph representing a telephone service call 
processing sequence, 

storing said logical graph in a logical graph template 55 
library within said storage means to be used in 
providing the defined telephone service, 

retrieving a logical graph template from said template 
library when said telephone service is to.be provi- 
sioned for a customer, and 60 

specifying customer dependent variables in said logi- 
cal graph template for provisioning customer ser- 
vice 

wherein said logical graph template with said speci- 
fied customer dependent variables can be sent to a 65 
service control point for interpretation by an inter- 
pretive process to provide service. 



2. The method according to claim 1 wherein said step 
of defining new nodes comprises the step of 

specifying the name of one of said new nodes. 

3. The method according to claim 2 wherein said step 
of defining new nodes comprises the step of 

specifying the node type of said one new node. 

4. The method according to claim 2 wherein said step 
of defining new nodes comprises the step of 

specifying the data type of parameter values associ- 
ated with said one new node. 

5. The method according to claim 4 wherein said step 
of defining new nodes further comprises the steps of 

specifying validation rules for parameter values asso- 
ciated with said one new node, and 

specifying an error message to be displayed in re- 
sponse to the failure of either said data type or said 
parameter values to satisfy said validation rules. 

6. The method according to claim 1 wherein said step 
of defining new nodes comprises the step of 

displaying selected ones of the defined new nodes. 

7. The method according to claim 1 wherein said step 
of graphically interrelating includes the step of 

adding either a new or previously defined node to 
said call processing sequence. 

8. The method according to claim 1 wherein said step 
of graphically interrelating includes the step of 

deleting either a new or previously defined node from 
said call processing sequence. 

9. The method according to claim 1 wherein said step 
of graphically interrelating includes the step of 

interconnecting two of said set of assembled nodes in 
said call processing sequence. 

10. The method according to claim' 1 wherein said 
storage means comprises: 

a node library for storing said new and previously 
defined nodes, said service definition library and 
said template library. 

11. The method according to claim 1 wherein said 
logical graph can be defined as a complex node and 
stored for later use and recall in said node library. 

12. A system for defining software implemented ser- 
vices in a telephone network having a service control 
point and programmable facilities of having executable 
service primitives, said system comprising: 

a node data store for storing groupings of said service 
primitives as primitive nodes; 

a service definition data store; 

a call processing record template store; 

a graphical user input and display device; and 

service creation process means for retrieving from 
said node data store any number of said nodes and 
displaying said nodes on said graphical user input 
and display device as a graphical symbol wherein a 
user using said graphical user display device can 
select from said nodes a set for defining a service 
and store said set of nodes together as a service 
definition in said service definition data store, ma- 
nipulate said set of nodes into a graphical abstrac- 
tion of a logical service process, and store said 
graphical abstraction of a logical service process as 
a call processing record in said call processing 
record template store, and wherein customer data 
can be added to said call processing record tem- 
plate store and sent to said service control point to 
provision services for a customer. 

13. The system according to claim 12 wherein said 
service creation process means further comprises means 
for defining at least one new node of service primitives 
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by specifying a node name, a node type, and a new set 
of node properties comprised of parameter values and 
means for storing said new node in said node data store. 

14. The system according to claim 13 wherein said 
service creation process means further comprises means 
for modifying said nodes by changing the values for 
properties that make up said nodes. 

15. A system for defining software implemented ser- 
vices in a telephone network having programmable 
facilities consisting of executable service primitives, said 
system comprising: 

a node data store for storing groupings of said service 
primitives as primitive nodes; 

a service definition data store; 

a call processing record store; 

a graphical user input and display device; and 

service creation process means for retrieving from 
said node data store any number of said nodes and 
displaying said nodes on said graphical user input 
and display device as a graphical symbol, said ser- 
vice creation process means comprising: 
means for defining at least one new node of service 
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means for specifying an error message to be 
displayed in response to the failure of either 
said node type or said parameter values to 
satisfy validation rules; and 
means for storing said new node in said node data 
store, 

wherein a user using said graphical user display de- 
vice can select from said nodes a set for defining a 
service and store said selected set of nodes defined 
as a service in said service definition data store, 
manipulate said set of nodes into a graphical ab- 
straction of a logical service process creating a call 
processing record logic tree and store said call 
processing record logic tree in said call processing 
record data store, and wherein said user can add to 
said graphical abstraction of a logical service pro- 
cess customer data creating a customized call pro- 
cessing record to be sent to a service control point 
to be executed when service is requested. 

16. The system according to claim 15 wherein said 
service creation process means further includes means 
for adding a node from said node data store to said call 
processing record logic tree. 

17. The system according to claim 16 wherein said 



primitives by specifying a node name, a node 2 5 service creation process means further includes means 



type, and a new set of node properties comprised 
of parameter values said means for defining at 
least one new node further comprising; 



for deleting a node from said call processing record 
logic tree. 
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